[HN Gopher] Ask HN: Xcode users - how do you make it more usable?
___________________________________________________________________
Ask HN: Xcode users - how do you make it more usable?
I've come from JS in VSCode (with loads of extensions) to Swift in
Xcode. In XCTest, I miss the red and green diffs between expected
output and actual output. In Xcode itself, I miss the ability to
perform code refactoring easily (extracting code to new files etc -
more than just extracting to new functions). I also miss linting /
prettier. What tools and plugins for Xcode do you all use to make
developing Swift in Xcode faster and easier? General Xcode hints
and tips welcome.
Author : isomorph
Score : 60 points
Date : 2022-09-25 14:20 UTC (8 hours ago)
| ProfMeowsworth wrote:
| Swiftlint[1] is nice and can be integrated into Xcode's warning
| panel. For auto-formatting, you can press CTRL-i on any selection
| to auto-format.
|
| [1] https://github.com/realm/SwiftLint
| Arcanum-XIII wrote:
| I developed in ObjC till 2016, so my opinion are dated but:
|
| - Xcode is an acquired taste. A bit slow and crash prone, but
| most of my issues came from the frameworks. Completion and
| linting were good enough and the integration with dtrace was
| enough to help me move faster than my colleagues. I even did use
| Xib :D
|
| - I tried multiple time app code: it's not good either. In fact,
| I don't like most of the jet rains product, but they're easier to
| set up than the competition so....
|
| - but now I'm back to nvim or emacs.
|
| I don't develop as my job anymore, so my tooling seems pretty
| barebone to what seems to be the trend :) I nearly make do with
| the Processing/Arduino IDE and they're both horrible.
| kitsunesoba wrote:
| For me the biggest factors for making Xcode "happy" are:
|
| - Writing clean/idiomatic Swift. This might sound silly but a
| lot of SourceKit instability is tied to things that are code
| smells, like deeply nesting closures and ridiculously long
| optional chains. Writing "Objective-C in Swift" where you're
| trying your best to ignore types will also make SourceKit
| grumpy.
|
| - Avoiding huge frameworks. Small focused single purpose
| libraries are fine, but gangly monster types can cause problems
| (and with UIKit available, likely unnecessary).
|
| - Avoiding storyboards. For several years I've been going code-
| only on iOS, with XIBs being used only on macOS because there
| they're more natural. Storyboards are more trouble than they're
| worth on either platform.
|
| - Using SwiftUI only for small, focused components. It still
| needs some time in the oven to be able to compete with code-
| only UIKit for speed/stability.
|
| With those Xcode is quite snappy and reliable, allowing me to
| work all day with no issue.
| soylentgraham wrote:
| Yeah, nobody should be using UIbuilder and storyboards any
| more. swiftui is so much better, faster, usable, extensible.
|
| But wow, the hoops you jump through to use it with c++ - via
| obj-c (And iirc can't use .mm files either). Im sure I wasn't
| helping things by exposing that to javascript too :)
| KerrAvon wrote:
| Xcode stability has markedly improved since 2016, FWIW.
| oneplane wrote:
| I think your main pain point stems from the difference in
| ecosystems. This is not even a good/bad thing, just a "things are
| done a bit different" thing.
|
| If you take a look at the functionality that you are after,
| perhaps moving out outside of the scope of the editor may help
| you far more than trying to re-compose the editor to be more like
| something that it isn't.
|
| I personally don't have much of an issue switching between them,
| I mostly prefer Sublime Text over everything but it doesn't have
| the features I need for everything so I just use whatever tools
| the project needs the most. For iOS and macOS the whole workflow
| split in two parts: a common CI part where all the external tools
| run, and the in-editor part where you mostly just write the
| features you want. This applies to AppCode too, but we also do
| that for C# code where it really doesn't matter if you do it in
| Rider or Visual Studio on Mac, Visual Studio on Windows or Visual
| Studio Code anywhere. In the end, the pre-commit and CI tasks
| will do the common workflow anyway.
|
| While I understand that people enjoy digging deep into the
| features of a single specific IDE to do everything, in reality
| this is probably not the 'best of all worlds', unless you are
| working solo.
| manmal wrote:
| One thing I've really come to appreciate (applies to all code
| editors) is to actively use keyboard shortcuts for moving
| selected lines up/down, and for deleting the current line. Vim
| users will be used to this anyway, but for the rest of us it's a
| great way to code faster.
|
| The other thing (since Xcode's clipboard feature is IMO clunky)
| is to use a clipboard manager with the history set to a decent
| size. I use Paste (happens to come with SetApp) and never once
| lost a copied snippet - it's rock solid. I've developed a habit
| of just copying whole files in case I want to revert to that
| state (or partially) later.
| pgt wrote:
| I improved Xcode usability by ceasing to make iOS apps.
| lizardactivist wrote:
| You don't. You ignore it and use AppCode instead.
| soylentgraham wrote:
| You do, just learn xcode instead of learning appcode. Get used
| to instruments, debugger, etc
| tcldr wrote:
| Xcode definitely has it's issues but I think they're moving to a
| system where Swift, and the Swift Package Manger specifically,
| can provide a bunch of this kind of functionality.
|
| Take a look at this 'Meet Swift Package Plugins' talk from WWDC
| 22 which goes into detail:
| https://developer.apple.com/videos/play/wwdc2022/110359/
|
| What's nice about this is that it's not restricted to Xcode, it
| can be integrated with your CIDI, too.
| a9ex wrote:
| 1) Here are some tips & tricks for refactoring:
| https://developer.apple.com/documentation/xcode/finding-and-...
|
| The "rename in project" and "rename in scope" functions are quite
| neat.
|
| 2) Check out SwiftLint: https://github.com/realm/SwiftLint
|
| I have not used it in a while, but it comes with good defaults
| and is highly customizable to your own preferred Swift style.
| [deleted]
| nchase wrote:
| I don't spend very much time in Xcode.
|
| I try to use the command-line tools instead.
|
| xcodebuild and xcrun are solid. check out xcpretty[^1] to improve
| the output of xcodebuild.
|
| Here's a blog post that someone wrote about using xctest from the
| terminal with xcpretty to make the output nice:
| https://mokacoding.com/blog/running-tests-from-the-terminal/
|
| [^1]: https://github.com/xcpretty/xcpretty
| throwaway1777 wrote:
| You get used to it. I don't find myself missing any of those
| functions.
| zkirill wrote:
| 1. Have a dedicated Apple machine for Xcode. Don't put anything
| else on it.
|
| 2. Reformat (clean install) machine every 1-2 months.
|
| 3. Upgrade machine every 1-2 years.
|
| * Regularly export and back up your Xcode developer profiles and
| certificates.
|
| * If you're thinking about doing something fancy, don't. It will
| come back to haunt you in ways you cannot even imagine.
|
| Source: 10+ years of iOS development.
| kitsunesoba wrote:
| Been doing iOS dev professionally for 7 years, and have been
| tinkering with Mac development since OS X 10.1 or so.
|
| I haven't found any of this to be necessary. I only reformat
| every 2-3 major releases at most and sometimes go most of the
| lifetime of a machine without reformatting, and I have various
| backend and cross platform desktop dev stuff set up on the same
| machines. Have rarely if ever had issues with Xcode acting
| up...
|
| Is there something we're doing differently to get such
| dramatically different outcomes?
| [deleted]
| thought_alarm wrote:
| This is great advice for people who don't know how computers
| work.
| jmull wrote:
| LOL, I just deleted my sibling reply... you put it so much
| better than I could.
| hyperjeff wrote:
| 20+ years of Xcode. This advice is ludicrous. Something
| traumatic must've happened 10 years ago to produce this policy.
| I only ever reboot for system updates and run zillions of
| things happily along with Xcode and many other full dev
| environments at the same time.
| laumars wrote:
| Man that sounds depressing. I didn't even reformat macOS 8&9
| and Windows 9x that frequently, and I consider them the dark
| times for operating systems.
| pivo wrote:
| I've been developing on a Mac with XCode for years and never
| done this. It's just not necessary.
| dagmx wrote:
| Why on earth are you clean installing so often? Are you
| polluting your main environment with a bunch of homebrew
| libraries per chance?
| smoldesu wrote:
| > 2. Reformat (clean install) machine every 1-2 months.
|
| This drove me _crazy_ when I developed on Mac. It must be a
| combination of Homebrew issues and MacOS idiosyncracies,
| because there 's no escaping the feeling of a "dirty" machine.
| A few good months of MacOS dev work can make a formidable
| machine feel like a decades-old UNIX environment.
|
| If you do general-purpose development on MacOS, I _beg you_ :
| please use Nix. The dev experience is head-and-shoulders above
| Homebrew or MacPorts, and the package selection is immense.
| Learn Flakes, and your cross-platform dev experience will feel
| downright magical.
| capableweb wrote:
| > like a decades-old UNIX environment
|
| Hey now, I've been running the same Arch installation for
| close to a decade with tons of random stuff tried and
| installed on it, borked the whole thing a few times but
| managed to recover, and it doesn't feel old at all. It is
| much leaner than my partners one year old MacBook in fact,
| even if the specs of the machine are worse!
| [deleted]
| oneplane wrote:
| This makes no sense at all. I'm on Monterey right now, with a
| OS install and user that has been with every upgrade and Time
| Machine migration to new hardware since 10.3 (2003). That's
| 19 years of upgrades, virtual machines (which always have
| programs that mess with networks, kernel extensions and file
| handlers), package managers (including Fink, Macports and
| brew) and devtools (including many JetBrains products, Xcode,
| Sublime Text, BBEdit, VSCode, Atom (which is now dead),
| Docker Desktop which I replaced with Rancher Desktop and then
| have Podman on the side. Even the Apple mail app has had its
| database upgraded all those years, as did iTunes (which
| eventually became Music).
|
| On a second machine that started from 10.5 onwards (on a
| PowerMac G5) I have a nearly identical setup that ended up in
| the same state but also had the hop to M1 done. No "eek my
| Mac feels so dirty" there either.
|
| Granted, I have a Debian install on yet another machine that
| has been with me since Woody (2002-ish), and that is
| similarly just upgraded over the years, switched from 32-bit
| to 64-bit in-situ, switched between ext2/3, ext4, ZFS, root-
| on-zfs, from BIOS to UEFI, and it still works great.
|
| I think that while the OS and vendor definitely have an
| impact, it's really going to depend on the user how it works
| over time.
| alerighi wrote:
| I bought my Mac in 2015 and I've upgraded from every release
| of the OS to the other, used for development, even changed
| hard drive (good times when you could do it) and copied my
| old installation with Time Machine. When I started using it
| the standard was MacPorts, then brew started to gain interest
| and I switched to it. I used Xcode, Android studio, IntelliJ,
| and a ton of development tools, and still it works without
| any issue.
|
| The thing is that as every OS it needs maintenance, every
| year or so I take a day to cleanup the system, remove caches,
| leftover from old installations, fix things that are not
| working, remove unused brew packages and applications that I
| no longer need, upgrade any software running on the machine,
| etc.
|
| > If you do general-purpose development on MacOS, I beg you:
| please use Nix
|
| After using macOS for a long time, I learned that the best
| thing to do is to use whatever stock configuration you have
| and touch as few things as possible. One example, I
| encountered a bug in React Native caused by the fact that in
| my PATH I had the GNU coreutils instead of the stock macOS
| one. If you keep things simple it's less likely that things
| break and if they break it's easier to fix them.
| SOLAR_FIELDS wrote:
| It's crazy how long this issue has existed. Homebrew
| complaining about XCode command line tools being an
| incorrect/outdated/nonexistent version is an issue I've faced
| every few months since I started developing on a Mac almost a
| decade ago.
| throwmcquaid123 wrote:
| Why hasn't Apple created its own official package manger?
|
| Homebrew is open source. Just fork it. They don't need Mike
| McQuaid.
| 95014_refugee wrote:
| There is one; you drag the app into /Applications to
| install it, and you drag it into the Trash to uninstall
| it.
|
| The "problem" is that 3p developers don't want to get
| with the program, and insist that the only possible way
| to install their magic sauce is to spam files all over
| the system. And that therefore there must be a super-
| complicated set of add-on tooling to deal with tracking
| all these files and their dependencies.
|
| It's job security, of a sort, I guess.
| odo1242 wrote:
| The main issues with dragging .app files (or their
| cousin, .pkg files) are:
|
| - That's only for GUI applications. Almost everyone
| reasonable developing GUI apps for macOS uses this
| method. However, CLI apps also have to update $PATH,
| which involves running a script. Package managers handle
| doing this better than macOS's frameworks because they
| were _designed_ to do such a thing.
|
| - There's absolutely no system for updates. Each app has
| a separate daemon consuming background resources just to
| check whether it has an update available for itself, and
| every app has a different way of actually installing the
| update. Just try having a system with Audacity, Adobe,
| Chrome, and Microsoft Office installed and you'll see
| what I mean (Microsoft Office and Adobe have a separate
| app installed just to update their original apps, Chrome
| installs updates in the background by sneakily updating
| its .app file, and Audacity just tells you an update is
| available and makes you restart the app to install it).
| This is why Homebrew manages .app files _despite_ the
| fact that a "package manager" already exists for these*.
|
| [note] I'm ignoring the App Store because most macOS
| developers don't submit their apps for the App Store
| because it's restrictive in many ways
|
| - Using a package manager allows saving storage space and
| RAM usage for dependencies - only one copy of a library
| is loaded into memory and stored on disk
|
| This is why apps to manage packages (e.g. Homebrew)
| exist. While we can debate the merits of Homebrew itself
| in terms of how well it does that, Homebrew does, in
| fact, solve a problem. If you believe it's not necessary
| to solve this problem, you can install the apps yourself,
| of course.
| dlyons wrote:
| Nix makes my dev life on MacOS _so_ much more manageable. The
| "dirty" feeling has, for the most part, gone away. I'm also
| able to easily share common config between other machines I
| use.
|
| Here's my Nix setup for my M1 Macbook using nix-darwin, if it
| helps anyone: https://github.com/dustinlyons/nixos-config
| kitsunesoba wrote:
| It's been a long time since I've played with Nix, do you
| still need to maintain a nixfile or whatever? Maybe I just
| wasn't "holding it right" but I recall not being able to
| just pop open a terminal window and do "X install Y" like
| with traditional package managers which was a turnoff.
| smoldesu wrote:
| I've got something very similar!
| https://github.com/toasterrepairman/boostrap/tree/main/nix
|
| It's also interesting to hear comments from the Nix
| detractors here. There's ample room to criticize the
| language and even the design philosophy behind the package
| manager, but it's a shame that most people never give it a
| "proper shot". Maybe that's the fault of Nix maintainers
| though.
| oneplane wrote:
| Lots of people can't "give it a shot" because it is so
| different from everything else. That's also why it has no
| foothold in any corporate environment. Even the amount of
| small businesses that use Nix for development is so small
| it's insignificant (but is exists).
|
| The main issue (I think) is that it boils down to "a
| worse shell script" shaped in a LISP kind of wrapper.
| Plenty of people know about LISP too but will simply not
| even look at it because it is too different. Even if you
| take away the functional paradigm it just doesn't look
| like anything that can map to an existing knowledge base.
| This is also why C-esque languages (and I'm talking about
| the non-edge-cases here) are so prevalent and successful;
| they don't have to be 'the best' or even 'good', they
| just have to be easy to map to existing knowledge to be
| useful. And Nix doesn't do that.
| waspight wrote:
| I still use the same installation of macOS as I began using
| seven years ago. I only moved it to new MacBooks a few times
| using the built in solution for that. I thought that
| formatting like crazy was a windows thing?
| willio58 wrote:
| It is, anyone who needs to clean install isn't running
| commands right, or doesn't fully understand what they are
| running when they run commands
| dagmx wrote:
| Especially because it's all relatively self contained.
|
| Removing brew stuff is trivial, and with sip being the
| default it's really hard to put the machine in a state
| that requires a clean install.
|
| I'm really unsure how someone could put up with clean
| installing needing to be part of their workflow for that
| long without questioning whether that's normal or not.
|
| Even in the pre-sip days, I'd have to go out of my way to
| make my Mac unusable since it's a very opinionated
| platform of isolating data/apps into very specific
| locations.
|
| unless a kext is involved. Then all hell breaks loose.
| Pinus wrote:
| Googling around for answers to Mac related problems, I
| can easily see that about half the people "answering"
| questions are completely clueless, just cargo-culting
| various voodoo stuff. I suspect that among the other
| half, half of _those_ are equally clueless, but I can 't
| tell which ones because I'm myself not mac-savvy enough!
|
| And Xcode itself does not help. I install Xcode. Well,
| actually, I didn't, because you need to actually _start_
| Xcode for it to completely install itself. It seems to
| come with a complete set of command-line tools; I can
| compile and run plain Unix stuff from the command line.
| Great. Except when you try to run Homebrew, that
| complains that you don't have the True Command Line
| Tools; you need to run xcode-select --install to install
| what appears to be a completely different copy of the
| same things. Wtf?
| jrmg wrote:
| Or it's an elephant powder, and they just think that it's
| doing something.
|
| What are the symptoms of an 'unclean' Mac? It should be
| possible to say with some exactness what's causing them
| with the use of diagnostic tools like 'top', or just the
| Activity Monitor app.
|
| I'll admit that _fixing_ issues might not be
| straightforward - but I can't recall the last time I
| reinstalled my Mac aside from buying a new one with a new
| installation - although I don't think that should really
| count...
|
| _Dave is out walking early one morning. The streets are
| quiet, but for one man sprinkling a white powder along
| the middle of the road. Intrigued, Dave approaches the
| man and asks what he is doing.
|
| The man explains he is sprinkling elephant powder - he
| does it every morning. Dave is visibly puzzled. The man
| continues "it keeps the elephants away".
|
| Dave, still puzzled, says "But there are no elephants
| here!".
|
| In agreement the man exclaims "Great stuff, isn't it!"_
| smoldesu wrote:
| The problems associated with impure programming
| environments are well-documented, I should hope I don't
| need to repeat them here. Anecdotally though, the
| packaging for lots of popular programs (rabbitmq, minio,
| mongo) is pretty consistently terrible. Many packages
| lack behavioral parity between x86 and ARM (software is
| installed to different locations) and linking becomes a
| total headache when your libraries are spread out across
| /opt/ and your lib folder. On top of that, Homebrew is
| extremely slow and processor-intensive, and demands root
| access for trivial operations. It's unsafe, impure, and
| wastes my time.
| d3nj4l wrote:
| What are you talking about? Homebrew flat out refuses to
| work under sudo.
| oneplane wrote:
| Are you seriously suggesting using system-wide
| installations and modifications to run _development
| environments_? Even if all else fails, you should at
| least have a chroot for that. Or if you don 't know how
| that works, virtual machines have been a thing for
| decades. Vagrant exists. Containers exist, heck, even in
| a user-friendly button-click interface with Docker...
| jbverschoor wrote:
| For me it's 15 years of upgrades, including betas.
| Everything is fine
|
| Just don't run things as root you don't understand /
| copy/paste blocks of shell script because stack overflow
| says so
| MrWiffles wrote:
| Nix? Are you talking about the package manager from NixOS? I
| didn't know that was MacOS-friendly these days, neat! Can you
| link us to any good articles discussing differences between
| it and Homebrew?
|
| Also, what is/are Flakes?
| lambdaba wrote:
| Nix can manage Homebrew (via nix-darwin) too! home-manager
| works great too.
|
| Re: flakes, IMO, don't worry about them too much, Nix is
| complicated as it is.
|
| IME while the package selection is indeed huge it does
| happen the odd package is missing or temporarily broken. In
| that case, I just use Homebrew via nix-darwin.
|
| [edit]: okay, maybe do learn about Flakes, I've read
| parent's comment and got the part about helping with cross-
| platform stuff, plus Flakes are the future. But you might
| not need those features right away, people have been
| happily using Nix for years without them.
| jdmoreira wrote:
| Sorry. Equally 10+ years of daily iOS development.
|
| Is Xcode annoying at times? Sure. Do I like deleting the
| DerivedData folder once in a while? No.
|
| But I really can't relate much to what you wrote except maybe
| upgrading your machine often.
| tcldr wrote:
| Really? Xcode has its issues but it isn't Charles Manson...
|
| Just a cleanup of ~/Developer/Xcode/DerivedData every once in a
| while seems to keep it ticking over for me.
|
| There was a time when the cache of simulators from every Xcode
| would build up and eat all you disk space just appearing under
| the amorphous grey 'System Data' categorisation under the
| 'About this Mac...' storage tab, but think they might have
| finally sorted that out.
|
| I do still need to relaunch Xcode every few hours as it
| struggles with 100s of files open and suddenly I get a keyboard
| lag or copy paste refusing to work.
|
| I'd definitely like to see something more lightweight for
| actual code editing, maybe de-coupling the SDK, and providing a
| decent LSP client that can be used with any language... but I
| don't see that happening anytime soon.
| generalpf wrote:
| Under Preferences > Locations you can make DerivedData
| relative to each project and I recommend you do that so
| different apps you work on don't force you to wipe all the
| artifacts from all apps when you clean it manually.
|
| As for removing old simulators after you remove an old Xcode,
| run
|
| $ xcrun simctl delete unavailable
| KMnO4 wrote:
| Check out AppCode by JetBrains. It reduces the need to use Xcode
| by 90%.
|
| https://www.jetbrains.com/objc/
| bouk wrote:
| Remove the print key binding and bind quick open to cmd+P
| happytoexplain wrote:
| Why haven't I thought of this. I frequently accidentally hit
| the print shortcut, and the quick open shortcut is ridiculously
| inconvenient for such a common navigation action.
| Kwpolska wrote:
| Why the heck is Cmd+P the key binding for Print, in Xcode, in
| 2022? Has anyone ever printed anything from Xcode?
| jasmes wrote:
| I'd just switch to JetBrains AppCode, but I'm very partial to
| their IDEs.
| princevegeta89 wrote:
| By switching to AppCode. In my experience Xcode sucked
| danpalmer wrote:
| Lots of people mentioning AppCode as a replacement, but damn
| JetBrains apps suck if you're used to macOS. Basic things like
| windows misbehaving, poor multi-monitor support (yes, really),
| and being unusably slow for almost every aspect of the user
| interface. I could go on, but if you hate Xcode I think you'll
| find AppCode to be just a different set of crap. If you like
| using a Mac you'll positively hate AppCode.
|
| I personally have little problem with Xcode now. My
| recommendations would be: don't use the built-in source control
| integration, it mostly sucks. Get an M1/M2 Mac, the speed boost
| is great. Use a lighter weight editor (not IDE) for editing data
| files, large text files (>5k lines) and for anything that's not
| Swift/Obj-C/UI work. And lastly, stay up to date. Xcode has
| crashed much less for me on 12/13/14 than it did on ~9/10/11.
| princevegeta89 wrote:
| Not sure if you had any setup issues, but Jetbrains IDEs have
| been just as great on Mac OS as on Windows or Linux. In some
| ways, they were even better vs Windows/Linux because of the
| better font rendering as a result of Retina + the high
| resolution displays. The only change I had to make was the set
| the keymap to classic(was used the classic layout on Windows).
| Everything else worked just great.
|
| On the contrary, XCode seemed to be incredibly feature crippled
| and going backwards (in terms of how they have a counter-
| intuitive design for the average developer). If It wasn't for
| the iOS work I had to do, I would have never even opened that
| IDE for a second time. I hated how Apple forced us to stick to
| Xcode and change our orientations and get used to their IDE,
| without leaving a second option...... until AppCode finally
| arrived. This is the best thing that happened to iOS
| development. Similar to Android finally partnering with
| Jetbrains to get out the Android Studio.
|
| Long live Jetbrains.
| Larrikin wrote:
| I've never used Jet Brains products on anything besides MacOS
| for close to a decade and have been doing professional Android
| development with Android studio for almost that long. I don't
| agree with any of your complaints and find it hard to believe
| they were ever true unless you used their products an extremely
| long time ago before they got popular.
|
| I had to use XCode in grad school for a single iOS class and
| ended up switching to app code for any parts of the assignments
| I could. At work the developer that switches back and forth
| between iOS dev and Android dev and he has a similar work flow
| of doing as much as possible in AppCode until forced to use
| XCode.
| danpalmer wrote:
| I use Android Studio on a ~weekly basis, and have tried to
| get into PyCharm many times. It's clear that the JetBrains
| team have a very different view of what UX is and should be
| than Apple and most developers targeting macOS.
|
| The fact that JetBrains uses its own UI toolkit is the cause
| of a lot of the friction I experience, it's buggy on multi-
| monitor systems, focus works in a different way interrupting
| many micro-interactions. The pseudo-windows-in-a-window model
| feels wrong on macOS, it's the only application I know like
| it and it's a very Windows like model.
|
| People value different things, and I know many get lots of
| value out of JetBrains products. I just suspect that most
| people working on a Mac because they like Macs will not align
| well with the JetBrains products.
| danpalmer wrote:
| More nuanced ideas... I set up my keyboard shortcuts to be as
| close to VSCode as I could so that Xcode and VSCode were very
| similar to write code in. I learnt the shortcuts for the UI -
| toggling panels and things, that was quite beneficial.
|
| Another approach is to find the bits that are _great_ and that
| you don't get with other platforms. The debugging, particularly
| UI debugging with the visual hierarchy is great. When you have
| a good set of schemes set up for different purposes,
| potentially tied in to scripting in the build process, you can
| get quite a flexible system for running apps under different
| environments.
| Cloudef wrote:
| Use xcodebuild and forget xcode
| jdmoreira wrote:
| I have one single tip. Don't use storyboards / nibs. Write all
| you view code by hand. Stackviews and your own layer of helper
| functions are you friend. I can write UI faster in code than
| would ever be possible in nib tooling. To say nothing of managing
| conflicts in those files. You won't look back!
| Jemm wrote:
| VM on pc with lots of ram. Works fine for me.
| stoeckley wrote:
| for me, main thing is turning on the (now native) vim emulation
| which is decent though missing some things (dot operator
| please!), and learning the keyboard shortcuts for the various UI
| panes
|
| for "prettier" all I've ever needed is just auto indentation of a
| block, which works fine
|
| other than that, I just submit to what Xcode is and live with it
___________________________________________________________________
(page generated 2022-09-25 23:01 UTC)