The joys of creating Xcode project files(nibblestew.blogspot.com)
nibblestew.blogspot.com
The joys of creating Xcode project files
https://nibblestew.blogspot.com/2021/04/the-joys-of-creating-xcode-project-files.html
121 comments
It's pretty sad how bad both iOS and Android development ecosystems are. Xcode is crap, homebrew is crap, gradle is crap ... Basically all tools hate automation. SPM seems like thing that could make things better, but it's swift only. Also the build times are ridiculous. How I wish I could just run compiler on a text file and run the god damn program I wrote on the device I own, like on every other sane OS.
This is why the JavaScript people said screw the whole thing and worked on porting web-esque development to mobile rather than trying to learn how to develop native apps. The difference in developer velocity is obscene. The only close native competitor I can think of is Flutter, which ironically is severely hampered by having to interoperate with Xcode (the thing that takes the most time out of any other task is compiling a production build). Flutter uses Dart which almost reads like vanilla JavaScript, and instead of dealing with the native UIs they just used Skia[1] to draw pixel-perfect equivalents for each platform (as opposed to React Native, which attempts to use the actual UI components and make them available in JS).
[1] https://skia.org/docs/dev/flutter/
[1] https://skia.org/docs/dev/flutter/
Funny enough there has been a long standing issue (as in years) with metal shaders that make the first minute or so of animations in flutter stuttery as the shaders compile.
Presumably (asking out of curiosity, completely naive) there's no way to AOT compile them?
Kind of? But there seems to be a bunch of barriers in making it happen:
https://github.com/flutter/flutter/issues/61045
SkSL warm-up doesn’t help newer iPhones using Metal.
Flutter recently migrated from OpenGL to Metal for all newer iOS devices. (Please reference Metal on iOS FAQ on which iOS devices are considered new enough to use Metal.) However, Skia currently only implemented the SkSL warm-up for OpenGL. So the SkSL warm-up would only speed up older iOS devices by default. If you find shader compilation jank to be an issue for your app on newer iPhones, please let us know by filing a GitHub issue. In the longer term, we have a plan to use test-based shader warm-up to mitigate this. If there’s an urgent need for fixing shader compilation jank on newer iPhones, please leave feedback on Issue 61045, and we can help you turn on OpenGL for your app.
https://github.com/flutter/flutter/issues/61045
Two weeks ago on reddit
"Shader precompilation for Metal has landed in Skia:"
https://www.reddit.com/r/FlutterDev/comments/mq1ouu/advices_...
and comment from last week on a flutter issue say it's working for them on the master channel. https://github.com/flutter/flutter/issues/79298#issuecomment...
and comment from last week on a flutter issue say it's working for them on the master channel. https://github.com/flutter/flutter/issues/79298#issuecomment...
Other comments in other tickets said it might not be the complete solution, and it's not released on stable yet. I hope it works, but it might not.
It's also a bit indicative that this kind of issue is left standing for years. The desktop resize jank one similarly took years to resolve.
It's also a bit indicative that this kind of issue is left standing for years. The desktop resize jank one similarly took years to resolve.
Ironically for hobby projects I've been using react-native as well, because it really makes developing a app faster, even though it will be bloated as hell. It's funny how even flutter decided to go with "new language" route. I guess NIH is strong in Android and iOS ecosystems.. I miss maemo/meego ...
Maemo is still around in the form of Maemo Leste. There are also various other open source mobile projects, notably postmarketOS. In terms of hardware, the PinePhone and Purism Librem 5 are projects aimed at non-Android open source operating systems like Linux/BSD.
https://maemo-leste.github.io/ https://postmarketos.org/ https://wiki.debian.org/Mobile#software-distros https://www.pine64.org/ https://puri.sm/
https://maemo-leste.github.io/ https://postmarketos.org/ https://wiki.debian.org/Mobile#software-distros https://www.pine64.org/ https://puri.sm/
Can you elaborate on the bloated part? I created a simple HN clone in React Native (without expo) and after publishing to Play Store, the app size was under 10MB.
Simple color picker app I made is 25MB. Even 10MB sounds pretty large for a simple app. But what I'm trying to say is more that I don't feel very hygienic considering using all these abstractions to develop a simple app, if I could just use the same C codebase to deploy for both platforms. Latter is technically possible, but nobody has created a framework around it similar to flutter or react-native. Flutter seems like the better option for the hygiene now though.
Honestly, that's why switching back to good old Linux feels so good for developers. If you know what you're doing, tossing up a C workspace takes 30 seconds, if you're slow. Using an honest-to-god free operating system is so much more liberating than bending your current setup to meet your needs.
I’m with you. The original applications of Project Builder, Interface Builder and TextEdit were better because they were focused.
Feature creep is never a good thing.
It’d have been better to build tools for Swift in its own right, allowing those tools to integrate - probably by using distributed objects.
But, it isn’t that way so such is life.
Feature creep is never a good thing.
It’d have been better to build tools for Swift in its own right, allowing those tools to integrate - probably by using distributed objects.
But, it isn’t that way so such is life.
I strongly disagree. I don’t want to have to open multiple tools when it should all interoperate together for the same effective high-level task. Unifying it all just allows for better (hypothetical) integration between all the parts.
Just remember — integration doesn’t mean it has to be bad or slow (current Xcode can always be improved).
Just remember — integration doesn’t mean it has to be bad or slow (current Xcode can always be improved).
Multiple tools doesn't mean that they can't interoperate. It's just that Apple (and everyone else) has given up on graphical IPC.
+1 for the term "graphical IPC." It is a huge pet peeve of mine that native apps choose to push new views onto navigation controllers instead of just opening a new window. They're looking to invent browsing history when there shouldn't be any (and if you need browsing history - use a browser!).
Ah, but if you open a new window, then users will have too many windows open and get confused or frustrated! You would need some kind of innovation in window management beyond the 1990s for that to be feasible.
But desktop OS vendors seem to still be operating under the paradigm of making their desktop environments as approachable by computer novices as possible. Maybe still a good business decision, but the future for desktop OSs is clearly with professionals and enthusiasts, and it's my hope more advanced human/computer interface approaches will follow.
You can have better window management facilities on Linux, but you have to choose between software that copies the mainstream paradigm of, as you say, pushing new views onto navigation controllers (and I'd add using tabs/split-panes built into the window itself instead of being offloaded to a more sophisticated window manager), or software that's quite rough around the edges.
But desktop OS vendors seem to still be operating under the paradigm of making their desktop environments as approachable by computer novices as possible. Maybe still a good business decision, but the future for desktop OSs is clearly with professionals and enthusiasts, and it's my hope more advanced human/computer interface approaches will follow.
You can have better window management facilities on Linux, but you have to choose between software that copies the mainstream paradigm of, as you say, pushing new views onto navigation controllers (and I'd add using tabs/split-panes built into the window itself instead of being offloaded to a more sophisticated window manager), or software that's quite rough around the edges.
What’s a graphical IPC? How would processes communicate graphically?
Not OP but my layman's understanding is that it would just be two GUI windows communicating over standard IPC. The current trend is for the entire application to be represented as a singular window, using navigation or tab controllers to switch between views rather than popping them out into their own windows.
Better window management paradigms aren't quite what I was referring to, but would also be great for mainstream software vendors to not have given up on. I use the Sway compositor on my personal machines to get some sort of reasonable window management tooling, which is lovely to the limited extent that even Linux software embraces composability in graphical environments. Would be nice to have similar tools on my work macbook.
Check out Amethyst for Mac OS. It’s a bit buggy, and it’s not Sway, but it’s Sway-like enough for me to get by on my work system.
With my particular workflow, tiling functionality without window-manager-level tabs is not enough of an improvement over the window snapping I can get with BetterTouchTool to justify another tool, but I am quite pleased with the availability of good third party window management tools on macOS. I understand that many people find tiling on its own quite useful (and my reliance on tabs restricts me quite a bit on Linux as well — to Sway, i3 and the ancient Notion).
Windows has at least one tool for tabbed windows though! Check out Stardock Groupy if that sounds like your sort of thing (and I swear there was another one but I can't find it, maybe Groupy is a rebrand?)
Windows has at least one tool for tabbed windows though! Check out Stardock Groupy if that sounds like your sort of thing (and I swear there was another one but I can't find it, maybe Groupy is a rebrand?)
More precise would be to say "graphical IPC control" or "graphical IPC initiation." I'm trying to point to the ability for users in a graphical environment to coordinate intricate communication between processes. Copy/paste and drag-n-drop are canonical examples, but I'd say that macOS tools like Alfred should also count.
> Just remember — integration doesn’t mean it has to be bad or slow (current Xcode can always be improved).
How is VS Code so popular, if its big brother Visual Studio can do everything it does and more?
Doesn't this signal that the market prefers lightweight IDEs over heavier ones?
Me personally, I would love to have a text editor on the left and the iOS simulator on the right and that's all you need to ship. Xcode Playgrounds attempted to execute this shift, but they still need much more attention until they can function as well as the regular workflow does (which is sad, 'cause the regular workflow sucks).
How is VS Code so popular, if its big brother Visual Studio can do everything it does and more?
Doesn't this signal that the market prefers lightweight IDEs over heavier ones?
Me personally, I would love to have a text editor on the left and the iOS simulator on the right and that's all you need to ship. Xcode Playgrounds attempted to execute this shift, but they still need much more attention until they can function as well as the regular workflow does (which is sad, 'cause the regular workflow sucks).
> How is VS Code so popular, if its big brother Visual Studio can do everything it does and more?
I only know extremely few people who'd use VS Code for C++, so "popular" is really ecosystem-dependent
I only know extremely few people who'd use VS Code for C++, so "popular" is really ecosystem-dependent
I use it. VS Code+clangd intellisense makes it easy to enumerate available classes, functions, and members, and because you don’t have to remember excessively verbose objects, writing self-documenting C++ is simple. Plus, you get automatic syntax checking as you go. That you can get these in a less-than-IDE nowadays is wonderful.
Visual Studio does not do a superset of what VS Code does. There's the very obvious difference in that VS is Windows-only while VSC is not (there is a Visual Studio for Mac, but it's a third unrelated program and not a Mac version of Visual Studio). Even if you are running Windows, VSC has more functionality than VS for non-C/C++/.NET development.
I’m a primarily backend dev who works on mobile apps sometimes, and I strongly agree. It’s a truly terrible and frustrating piece of software. It tries to do way too many things, and does them all poorly.
Even doing something as simple as upgrading Xcode via the App Store is painful, often progressing insanely slowly and taking hours or even tens of hours on an otherwise fast connection. It has been like this for years and years and Apple has done nothing to fix it, like most Xcode issues.
Even doing something as simple as upgrading Xcode via the App Store is painful, often progressing insanely slowly and taking hours or even tens of hours on an otherwise fast connection. It has been like this for years and years and Apple has done nothing to fix it, like most Xcode issues.
I want people who haven't used Xcode to understand that this isn't a connection issue, there is something specifically weird happening with Xcode when you try to upgrade it.
It has to be wed to the OS in such a way that makes the propensity for this vague failure state to occur, because I've never had it happen with anything else.
Upgrading from the App Store sometimes will hang at 99% and no matter what you do save some weird incantations to remove stuff from this secret App Store cache to remove the download to begin its excruciatingly slow download again, only with the hope in your heart this impenetrable and silent error doesn't happen again.
And of course none of this is addressed by Apple. You think you can just download versions from the developer site? Well enjoy, and I am not joking, a 30+ minute unzipping of the .xip file (yep that's right, it's not a .zip).
Apple does not care about it's developer ecosystem, even though you are such a huge part of it's success. It's apparent in their thread bare documentation, their terrible tools, their greedy practises.
I get it. They are a business. But they do not deserve their halo.
It has to be wed to the OS in such a way that makes the propensity for this vague failure state to occur, because I've never had it happen with anything else.
Upgrading from the App Store sometimes will hang at 99% and no matter what you do save some weird incantations to remove stuff from this secret App Store cache to remove the download to begin its excruciatingly slow download again, only with the hope in your heart this impenetrable and silent error doesn't happen again.
And of course none of this is addressed by Apple. You think you can just download versions from the developer site? Well enjoy, and I am not joking, a 30+ minute unzipping of the .xip file (yep that's right, it's not a .zip).
Apple does not care about it's developer ecosystem, even though you are such a huge part of it's success. It's apparent in their thread bare documentation, their terrible tools, their greedy practises.
I get it. They are a business. But they do not deserve their halo.
It used to be a zip, there’s a reason why they changed it to xip
I started downloading the dmg manually quite a few years back... and have never adopted the AppStore version. So painful.
This SO post is continually updated with the latest builds and is a bookmark for me. https://stackoverflow.com/questions/10335747/how-to-download...
This SO post is continually updated with the latest builds and is a bookmark for me. https://stackoverflow.com/questions/10335747/how-to-download...
You might also like https://xcodereleases.com/ which is updated automatically.
I believe it is actually updated manually.
And they tax the CPU pretty hard too.
This, so much this.
I have a fully loaded MBP 16” w/ i9, 32GB RAM and the fan starts very quickly due to indexing and whatever else it is doing.
I have a fully loaded MBP 16” w/ i9, 32GB RAM and the fan starts very quickly due to indexing and whatever else it is doing.
I have a 2016 MacBook Pro which has gradually become completely useless for swift development in Xcode. The computer sometimes randomly reindexes while I type, which can lag Xcode so much that it drops keystrokes. And as a result if I’m not watching closely, sometimes method names will come out garbled. To reiterate, Xcode makes my $3000 computer from a few years ago so slow that I can’t type the name of a function.
A few months ago I moved to a ryzen development machine running Linux mint to code rust using IntelliJ. Responsiveness and stability is night and day. It’s a shame, too - swift is a lovely language and I’d love to use it more. But life is too short to put up with Xcode.
A few months ago I moved to a ryzen development machine running Linux mint to code rust using IntelliJ. Responsiveness and stability is night and day. It’s a shame, too - swift is a lovely language and I’d love to use it more. But life is too short to put up with Xcode.
Crazy right? $3.5k and it can’t handle indexing / compiling Swift?!
Some other devs on the team just got M1s. They are backend though... so I haven’t seen an M1 running Xcode yet. Very curious but I am guessing it is night and day... for half the cost or less.
Some other devs on the team just got M1s. They are backend though... so I haven’t seen an M1 running Xcode yet. Very curious but I am guessing it is night and day... for half the cost or less.
> Xcode unironically made me try to change career from iOS developer to pen tester. I've spent way too much time in its guts and I think its left a little bit of taint on my soul. It is unfathomably bad.
I've been a mobile dev for many many years and most of my time was spent focused on iOS.
I didn't find Xcode that bad, but sometimes annoying issues do keep popping up, for example stuff related to provisioning profiles.
Last few years more of my time was spent with Xamarin and the macOS version of Visual Studio (rebranded Xamarin Studio) and it's quite a bit worse than Xcode. Xamarin Studio has the tendency to get really slow after extended usage and I pretty much never had such issues with Xcode. Few things are more frustrating to me (not to mention a huge productivity killer) than writing code in a slow, laggy editor. At least Xcode doesn't have that issue (most of the time).
However, what I really like is to be able to just use a simple text editor for my work. Lately, as a hobby and for side-projects, I've been using Sublime Text with LÖVE 2D (Lua) and this has been really fun to me. No project files to deal with, no complicated UI stuff (visual editors and the like), no more downloading of gigabytes of simulators after an update (as long as I focus on macOS & Windows that is), etc...
With MAUI, Microsoft will make the default Xamarin project structure also really simple, just a few lines of code. That should make it a lot easier to use a simple text editor for Xamarin dev work, instead of the slow Visual Studio for macOS IDE. Perhaps Apple should follow suit with Xcode.
I've been a mobile dev for many many years and most of my time was spent focused on iOS.
I didn't find Xcode that bad, but sometimes annoying issues do keep popping up, for example stuff related to provisioning profiles.
Last few years more of my time was spent with Xamarin and the macOS version of Visual Studio (rebranded Xamarin Studio) and it's quite a bit worse than Xcode. Xamarin Studio has the tendency to get really slow after extended usage and I pretty much never had such issues with Xcode. Few things are more frustrating to me (not to mention a huge productivity killer) than writing code in a slow, laggy editor. At least Xcode doesn't have that issue (most of the time).
However, what I really like is to be able to just use a simple text editor for my work. Lately, as a hobby and for side-projects, I've been using Sublime Text with LÖVE 2D (Lua) and this has been really fun to me. No project files to deal with, no complicated UI stuff (visual editors and the like), no more downloading of gigabytes of simulators after an update (as long as I focus on macOS & Windows that is), etc...
With MAUI, Microsoft will make the default Xamarin project structure also really simple, just a few lines of code. That should make it a lot easier to use a simple text editor for Xamarin dev work, instead of the slow Visual Studio for macOS IDE. Perhaps Apple should follow suit with Xcode.
As another primarly-iOS developer I agree. Xcode was better back when Interface Builder was separate (that merge never should've happened) but as a whole I don't find Xcode any more irritating than I find Android Studio (which has found some truly unique ways to be frustrating).
It will be interesting to see where things go in the coming years though, because between SwiftPM, SwiftUI, SourceKit, and the SourceKit LSP I think many of us may be shifting toward a workflow more centered around a light editor. A few days ago I was toying around with SourceKit LSP in Sublime Text 4 and it's surprisingly servicable - most of my projects have abandoned xibs/storyboards already so I could probably make that setup work if I put some time into getting Sublime's build system set up.
It will be interesting to see where things go in the coming years though, because between SwiftPM, SwiftUI, SourceKit, and the SourceKit LSP I think many of us may be shifting toward a workflow more centered around a light editor. A few days ago I was toying around with SourceKit LSP in Sublime Text 4 and it's surprisingly servicable - most of my projects have abandoned xibs/storyboards already so I could probably make that setup work if I put some time into getting Sublime's build system set up.
Did you manage to get SourceKit LSP picking up SPM dependencies? I tried it out with neovim last year and that was one issue I had. I’d probably do most of my editing in there if I could.
> I've been a mobile dev for many many years and most of my time was spent focused on iOS.
> I didn't find Xcode that bad, but sometimes annoying issues do keep popping up, for example stuff related to provisioning profiles.
In my experience, iOS/macOS devs have just kind of "got used to it" with regard to Apple's developer tooling. Once you know how to work with all of it at an advanced level it doesn't seem that bad.
I think the issue is when developers that haven't spent considerable amounts of time acclimating have to work with Apple's dev tools. If you haven't been hazed into being productive with Apple's tools, they won't work how you expect and it won't be obvious why.
> I didn't find Xcode that bad, but sometimes annoying issues do keep popping up, for example stuff related to provisioning profiles.
In my experience, iOS/macOS devs have just kind of "got used to it" with regard to Apple's developer tooling. Once you know how to work with all of it at an advanced level it doesn't seem that bad.
I think the issue is when developers that haven't spent considerable amounts of time acclimating have to work with Apple's dev tools. If you haven't been hazed into being productive with Apple's tools, they won't work how you expect and it won't be obvious why.
Isn’t that pretty much all IDEs if you come over from whatever you’re used to?
No, I would say most languages and IDEs are not as complex/bloated/unpredictable as Apple developer tools.
I’m a polyglot and love trying new languages and platforms. I’ve spent serious time with eclipse (Java), IntelliJ (rust), vscode (rust, javascript, typescript, C), vim (all), visual studio (C++, c#). I have lots of Apple devices, I care about platform-native software and I love the swift programming language. And call me crazy but I loved Xcode with Obj-C back when it was 3.x.
So I can say with confidence that writing swift using modern Xcode is the worst experience with an IDE I’ve ever had. Dropped keystrokes, random crashing, device-dependent compiler errors (“Error: this method spent too long type checking”). And so on. It’s an obvious, avoidable disaster zone. Dear Apple, fixing the bugs in your software is more important than adding new features!
In comparison, VSCode+Typescript and Visual Studio+C# are the best IDE experiences I’ve had. Fast, stable, smooth, reliable and easy to set up. And little things work well - like inline documentation, autocomplete, project wide renaming and integrated debugging. Microsoft nails it. IntelliJ+Rust is close but it has a few obvious rough edges.
So I can say with confidence that writing swift using modern Xcode is the worst experience with an IDE I’ve ever had. Dropped keystrokes, random crashing, device-dependent compiler errors (“Error: this method spent too long type checking”). And so on. It’s an obvious, avoidable disaster zone. Dear Apple, fixing the bugs in your software is more important than adding new features!
In comparison, VSCode+Typescript and Visual Studio+C# are the best IDE experiences I’ve had. Fast, stable, smooth, reliable and easy to set up. And little things work well - like inline documentation, autocomplete, project wide renaming and integrated debugging. Microsoft nails it. IntelliJ+Rust is close but it has a few obvious rough edges.
It's the only IDE I've used where I couldn't trust it not to crash. IDEs should not crash, even if rarely.
No software should crash; and if it does, you figure out why it crashes and fix the problem.
The fact that Xcode crashes reliably, and has done so for years without being fixed is a stain on apple’s reputation for making otherwise good products.
The fact that Xcode crashes reliably, and has done so for years without being fixed is a stain on apple’s reputation for making otherwise good products.
My own Xcode horror story:
It was the end of 2009. I was working for a small startup doing some Twitter clone. We decided that we want to provide an iPhone app, and since we already provided Twitter like API, the easiest way is to just fork an open source iOS Twitter app to replace all the API endpoints to ours.
I was doing that, using Xcode. One day the compiler complained something like "unexpected `\`". Looking at the code in Xcode, I don't see any \ around the position compiler pointing to.
After stared at the code for an hour, I finally decided to open that file in vim, and sure there's an \ added before a double quotation mark I believe, while in that context an escape is not needed (and doing that is wrong, thus the complaint from the compiler).
So Xcode's editor, trying to be smart, auto escaped a double quotation mark at the wrong place, and don't show it in the editor at all. Their compiler caught the error.
It was the end of 2009. I was working for a small startup doing some Twitter clone. We decided that we want to provide an iPhone app, and since we already provided Twitter like API, the easiest way is to just fork an open source iOS Twitter app to replace all the API endpoints to ours.
I was doing that, using Xcode. One day the compiler complained something like "unexpected `\`". Looking at the code in Xcode, I don't see any \ around the position compiler pointing to.
After stared at the code for an hour, I finally decided to open that file in vim, and sure there's an \ added before a double quotation mark I believe, while in that context an escape is not needed (and doing that is wrong, thus the complaint from the compiler).
So Xcode's editor, trying to be smart, auto escaped a double quotation mark at the wrong place, and don't show it in the editor at all. Their compiler caught the error.
My base stress level improved tremendously when I gave up iOS development and went back to the web. I don't have to deal with frustratingly broken tools every day or hold my breath every time I publish an update in case some random app store reviewer is having a bad day. Never again.
I would almost be compelled to use and develop for Apple products if Xcode wasn't so comedically bad.
> Canvas for SwiftUI previews for example
Automatic preview updating paused [Resume]
Automatic preview updating paused [Resume]
iOS development nearly broke me. It's the only language/platform/runtime that have hampered my ability to perform my job to the extent where it's taken a toll on my well being and confidence .
* Having to buy a computer, use a new OS, use a new editor and buy a new phone to just get started.
* MacOS, XCode and/or iPhone updating and breaking my own and third party code ad hoc.
* Having to know/learn C, Obj-C and Swift 1, 2, 3, 4 and 5. Being forced to constantly translate between these, and check timestamps on documentation/SO/guides to determine how much use there is in even skimming it as the amount of deprecation and half-implemented things that I'm not supposed to use in production means my confidence in implementation is near zero.
* Brittle pipelines, impossible fresh installs that break in the weirdest ways (Ruby? What?), publishing and generally interacting with Apple making otherwise quick actions take days.
* XCode not working great with GIT, having to reboot it when it randomly stops working all together, input latency, code highlighting that half of the time doesn't work at all or is very slow (on a brand new M1).
While I don't disagree that the pbxformat is awful, there are some reasons behind the design. Take the example of PBXBuildFile in the article. Here's a quote:
> There is no other data in this object. Its only reason for existing, as far as I can tell, is to point to the actual PBXFileReference object which contains the filesystem path.
Now, that statement is true most of the time. But not always. Let's say you have a file in two targets (targets ~= binaries). In one of those targets, you need to set a build flag, but not the other, how do you do it? Well, you set it on the PBXBuildFile, rather than the PBXFileReference. In otherwords, you can have 2 different PBXBuildFile's, with 2 different sets of flags, pointing at the same actual file on disk.
Whether that's a good design or not is definitely up for debate, but I wanted to clarify that there are reasons behind everything.
Going further:
> Since everything has a unique ID, a reasonable expectation would be that a) it would be unique per object and b) you would use that ID to refer to the target. Neither of these are true. For example let's define a single build target, which in Xcode/CMake parlance is a PBXNativeTarget. Since plist has a native array type, the target's sources could be listed in an array of unique ids of the files. Instead the array contains a reference to a PBXSourcesBuildPhase object that has a few keys which are useless and always the same and an array of unique ids.
Let's take a sub-statement here first: > Since everything has a unique ID, a reasonable expectation would be that a) it would be unique per object
The author claims this is false, but I've never seen a case where this hasn't held up. Numerous libraries depend on this fact.
> you would use that ID to refer to the target
Also claimed as false, but you do. The argument the author makes talks about the build file stuff I mentioned above, so they may just be misunderstanding or have mis-spoken/written.
Just to re-iterate, I'm not a fan of this format at all. I'm actually in the middle of converting a million line project to use XcodeGen just so I can get away from it. But everything does have a reason.
> There is no other data in this object. Its only reason for existing, as far as I can tell, is to point to the actual PBXFileReference object which contains the filesystem path.
Now, that statement is true most of the time. But not always. Let's say you have a file in two targets (targets ~= binaries). In one of those targets, you need to set a build flag, but not the other, how do you do it? Well, you set it on the PBXBuildFile, rather than the PBXFileReference. In otherwords, you can have 2 different PBXBuildFile's, with 2 different sets of flags, pointing at the same actual file on disk.
Whether that's a good design or not is definitely up for debate, but I wanted to clarify that there are reasons behind everything.
Going further:
> Since everything has a unique ID, a reasonable expectation would be that a) it would be unique per object and b) you would use that ID to refer to the target. Neither of these are true. For example let's define a single build target, which in Xcode/CMake parlance is a PBXNativeTarget. Since plist has a native array type, the target's sources could be listed in an array of unique ids of the files. Instead the array contains a reference to a PBXSourcesBuildPhase object that has a few keys which are useless and always the same and an array of unique ids.
Let's take a sub-statement here first: > Since everything has a unique ID, a reasonable expectation would be that a) it would be unique per object
The author claims this is false, but I've never seen a case where this hasn't held up. Numerous libraries depend on this fact.
> you would use that ID to refer to the target
Also claimed as false, but you do. The argument the author makes talks about the build file stuff I mentioned above, so they may just be misunderstanding or have mis-spoken/written.
Just to re-iterate, I'm not a fan of this format at all. I'm actually in the middle of converting a million line project to use XcodeGen just so I can get away from it. But everything does have a reason.
It is not necessary for bad software to remain bad. There may be a reason for some decisions, but it does not mean that such decisions must be permanent.
Xcode 12 UX is an example where Apple seemed willing to invest. There may be reasons pbxformat is bad, but there is no reason Xcode 13 or 14 couldn't address them. After all, it's only software.
Xcode 12 UX is an example where Apple seemed willing to invest. There may be reasons pbxformat is bad, but there is no reason Xcode 13 or 14 couldn't address them. After all, it's only software.
Apple controls the whole ecosystem, and third parties just can follow. If only Apple put the same effort in improving the development environment as they did during the introduction of Swift.
Agreed. I've been expecting Apple to replace this format with a much more diffable one for years. I doubt that will happen now with the new support for Swift packages and the xed command.
they may just be misunderstanding or have mis-spoken/written
90% of the tech rant blog spam on HN is people who don't fully understand the tool they're using.
Something doesn't work the way they expect for their particular project or their specific need, and they blather on about how bad it is.
When the reality is that these things are often done for a reason, but the author's myopia prevents him from understanding that there are other people doing other things in the world.
90% of the tech rant blog spam on HN is people who don't fully understand the tool they're using.
Something doesn't work the way they expect for their particular project or their specific need, and they blather on about how bad it is.
When the reality is that these things are often done for a reason, but the author's myopia prevents him from understanding that there are other people doing other things in the world.
This is 100% true, but it's also one of the more difficult things in life to understand. It's one thing to know that other people have other experiences and needs, but it's another to really constantly feel that.
I'd like to see more assumption of positive intent on here, but it's definitely a hard task. I hope I didn't offend the original author here. I tried to ensure that I explained without chastising.
I'd like to see more assumption of positive intent on here, but it's definitely a hard task. I hope I didn't offend the original author here. I tried to ensure that I explained without chastising.
It could certainly be mitigated if the creator of the software published less opaque documentation about it.
Absolutely. I spent forever reverse engineering the format to write a Python parser (https://github.com/microsoft/xcodeproj). It covers the projects I need it to (one in particular is very complex, probably in the top 100 most complex ones out there - I'm sure you can figure out which from my profile). However, there are plenty of areas I had to guess. And this is just for reading, no writing support has been added at this point.
There might be reasons for everything, but all those reasons soon become irrelevant when you try to merge a code that also changed the project file. Have fun. Xcode project generators at least solve this somehow, but they'll always play the chicken & egg game with upstream, and something won't work properly or needs nasty hacks.
This is actually the one feature where CMake really shines, and big kudos to the CMake team for this: IDE project file generation never breaks when new versions of those IDEs are released (or at least regressions happen extremely rarely and are fixed promptly).
This must be one of the most frustrating and unthankful tasks in the entire domain of programming.
This must be one of the most frustrating and unthankful tasks in the entire domain of programming.
cmake shudder
No thanks. I am one whom cmake has tried. When it works, it works well. When it doesn't, it is utterly impenetrable.
I actively avoid any GitHub projects that use cmake because it's just normally too painful to use, and it brings on an episode of PTS. Just writing this is causing my blood pressure to rise.
No thanks. I am one whom cmake has tried. When it works, it works well. When it doesn't, it is utterly impenetrable.
I actively avoid any GitHub projects that use cmake because it's just normally too painful to use, and it brings on an episode of PTS. Just writing this is causing my blood pressure to rise.
Hasn’t been updated in a while, but “Texts from Xcode” (https://www.textfromxcode.com/) has some fun collections of frustrations.
[deleted]
It's such trash. For my personal projects, XcodeGen is a lifesaver.
How Apple thinks that a single god file is a good idea is crazy to me. No other build tool needs this.
https://github.com/yonaskolb/XcodeGen
How Apple thinks that a single god file is a good idea is crazy to me. No other build tool needs this.
https://github.com/yonaskolb/XcodeGen
We use xcodegen at my work and it’s awesome.
A similar project from Google is Tulsi [1] but even though it can also generate xCode project files I think it’s more geared towards making iOS projects work well with Bazel.
[1] https://tulsi.bazel.build/
A similar project from Google is Tulsi [1] but even though it can also generate xCode project files I think it’s more geared towards making iOS projects work well with Bazel.
[1] https://tulsi.bazel.build/
I cannot imagine working on an iOS application that is meant to be maintained by multiple people that does not use Xcodegen.
Additionally, it is the only sane way I've found of handling whitelabel application development. Here's an example for anyone who wants to see it in action: https://github.com/onebusaway/obakit
Additionally, it is the only sane way I've found of handling whitelabel application development. Here's an example for anyone who wants to see it in action: https://github.com/onebusaway/obakit
What an incredible negativity here in the comments. I’d like to provide a counter and say that I’ve been developing in Xcode for a number of years now, and I think it’s fine. Is it great? No. But it’s fine and I’m very productive. My projects are generally small, meaning not more than 100-150k lines, maybe that is what causes problems for other people? Anyway, I’ve had good, solid fun with SwiftUI in the most recent year or two. The Preview canvas didn’t always work, but I usually found a workaround.
> What an incredible negativity here in the comments
This might seem strange, but I think the negativity here makes sense, and is justified on multiple fronts.
On a technical front, Xcode is pretty awful. It’s slow and unstable, and seems to have only gotten worse over the last decade. Many comments here express this in detail.
This matters so much because tools become an extension of our bodies. Using bad tools makes us feel ineffective, weak and slow. If I can’t trust Xcode to receive keystrokes (yes, a real bug I encounter frequently), my brain interprets that bug as me being physically impaired and unable to type. It’s awful.
This is made so much worse because Xcode - and any bad product from Apple - betrays Apple’s promise to it’s customers. Apple’s promise is “we sell premium products which are worth the extra cost because they’re delightful. Buy from us and we’ll take care of you”. Steve jobs used to say this sort of thing quite explicitly. This is why people hold Apple to a higher standard - because Apple promises a higher standard with their branding and their prices. It wouldn’t matter so much if Xcode were part of an open ecosystem and we had choice - I wasn't angry a few years ago when Atom was laggy and slow. I just shrugged, uninstalled and used something else. But iOS devs are mostly locked in. They have nowhere to go.
And practically speaking, people from all over the tech industry are on HN. Plenty of people at Apple are here - even if they can’t say so. Hopefully a bit of public shaming will be read by someone at Apple with the authority to right the ship. We can hope.
This might seem strange, but I think the negativity here makes sense, and is justified on multiple fronts.
On a technical front, Xcode is pretty awful. It’s slow and unstable, and seems to have only gotten worse over the last decade. Many comments here express this in detail.
This matters so much because tools become an extension of our bodies. Using bad tools makes us feel ineffective, weak and slow. If I can’t trust Xcode to receive keystrokes (yes, a real bug I encounter frequently), my brain interprets that bug as me being physically impaired and unable to type. It’s awful.
This is made so much worse because Xcode - and any bad product from Apple - betrays Apple’s promise to it’s customers. Apple’s promise is “we sell premium products which are worth the extra cost because they’re delightful. Buy from us and we’ll take care of you”. Steve jobs used to say this sort of thing quite explicitly. This is why people hold Apple to a higher standard - because Apple promises a higher standard with their branding and their prices. It wouldn’t matter so much if Xcode were part of an open ecosystem and we had choice - I wasn't angry a few years ago when Atom was laggy and slow. I just shrugged, uninstalled and used something else. But iOS devs are mostly locked in. They have nowhere to go.
And practically speaking, people from all over the tech industry are on HN. Plenty of people at Apple are here - even if they can’t say so. Hopefully a bit of public shaming will be read by someone at Apple with the authority to right the ship. We can hope.
Pretty much this.
We are producing a white-label mobile app which also runs on Apple devices. It's part of our build chain to modify bespoken Xcode project files. Of great help is this node library [0] which allows automating our build process which includes modifications to the Xcode project file.
[0] https://github.com/apache/cordova-node-xcode
[0] https://github.com/apache/cordova-node-xcode
Watch out, Apple might call your business model "spamming the app store":
> Don’t create multiple Bundle IDs of the same app. If your app has different versions for specific locations, sports teams, universities, etc., consider submitting a single app and provide the variations using in-app purchase.
> Don’t create multiple Bundle IDs of the same app. If your app has different versions for specific locations, sports teams, universities, etc., consider submitting a single app and provide the variations using in-app purchase.
Thanks, I appreciate your hint. We are aware of the app store policies -- and we are not affected. Our apps are owned and customized by our customers and each app has their own content. Imagine our solution as an app building toolkit.
As someone who has maintained such a system, there is a very real risk of this.
If the app is content-heavy, and that content varies between each instance of the app, they're more likely to be okay with it, but it is still a difficult road fraught with pain and risks.
If the app is content-heavy, and that content varies between each instance of the app, they're more likely to be okay with it, but it is still a difficult road fraught with pain and risks.
I’ve used the Cocoapods tool Xcodeproj to facilitate really nice Workflows that Xcode didn’t provide for me out of the box. I don’t need this in every project but when I do it’s a really nice API for manipulating the pbxproj files
https://github.com/CocoaPods/Xcodeproj
https://github.com/CocoaPods/Xcodeproj
Just wanted to chime in that you can, in fact, convert old ASCII plist files to modern JSON and XML and then convert them back: https://stackoverflow.com/a/46929480 shows how to use plutil in one direction, and you can convert back using the “pl” utility, I believe. It’s a bit confusing that one command converts to modern formats and a different command can convert modern formats back to legacy formats.
Under “standards”, the man page appears to have the following cheeky warning for pl: “The pl command obeys no one's rules but its own.”
https://www.unix.com/man-page/osx/1/pl/ or just type “man pl” or “man plutil” at Terminal.
Here’s an example of how to read and write an xcodeproj file using Python and these two utilities: https://gist.github.com/brunogama/3929457
Under “standards”, the man page appears to have the following cheeky warning for pl: “The pl command obeys no one's rules but its own.”
https://www.unix.com/man-page/osx/1/pl/ or just type “man pl” or “man plutil” at Terminal.
Here’s an example of how to read and write an xcodeproj file using Python and these two utilities: https://gist.github.com/brunogama/3929457
This tool doesn’t always work because plists can contain arbitrary Objective-C objects. However, there’s a relatively nice objective-c API that can be used to decode them losslessly that I used to extract data from Safari’s reading list l:
https://github.com/fiddlerwoaroof/objc-lisp-bridge/blob/mast...
https://github.com/fiddlerwoaroof/objc-lisp-bridge/blob/mast...
plists absolutely cannot contain arbitrary Objective-C objects. They support a subset of Foundation container and value types and are not extensible to contain other types.
Any Codable can be written to or read from plists, right?
Anyways, it’s definitely true that plists support a superset of the data types supported by JSON: plutil will not convert the Safari bookmarks file to JSON, for example.
Anyways, it’s definitely true that plists support a superset of the data types supported by JSON: plutil will not convert the Safari bookmarks file to JSON, for example.
No, property lists have a limited number of types that they support: https://developer.apple.com/library/archive/documentation/Ge...
As far as I know, any Codable can be roundtripped through plists: https://www.donnywals.com/reading-and-writing-property-list-...
So the answer is yes, both are true. On the one hand, a plist can only contain strings, floats etc. On the other hand, an app can use plist files to store whatever it likes, just as a text file doesn’t limit you to plain text if you want to use Base64, for example.
So while it is true that you can use these tools to convert a Plist from a binary or legacy format to JSON or XML and back, there are no guarantees you’ll be able to understand what was written to the plist originally.
The plist format does not encode metadata describing itself in any common standardized way: it’s not a JSONSchema, an XML Schema or even a protobuf .proto file. A well-written plist can be as self-describing as JSON or XML, though the concept of a schema for plist files doesn’t exist as far as I’m aware, outside of how apps choose to serialize objects, that is. (The data structures an app uses could be considered a schema for a plist but it assumes the data structures themselves are versioned when they need breaking changes…)
https://developer.apple.com/library/archive/documentation/Ge... has an example of “stringly-typed” keys and values. There’s not much validation in a generic plist editor just as there isn’t validation in JSON or XML by default, but any app can add its own validation to ensure what it saves to a plist is something it can read later… that’s where the confusion over objects and codables comes in. If an app wrote the object to a part of a plist, it can thus de-serialize it from how it wrote it. If your app doesn’t understand another app’s plist, that’s pretty normal for complicated files or data kept by third-party apps. Few apps consider metadata and longevity when they write to disk, such that migrations are handled version to version as they need to, etc.
So while it is true that you can use these tools to convert a Plist from a binary or legacy format to JSON or XML and back, there are no guarantees you’ll be able to understand what was written to the plist originally.
The plist format does not encode metadata describing itself in any common standardized way: it’s not a JSONSchema, an XML Schema or even a protobuf .proto file. A well-written plist can be as self-describing as JSON or XML, though the concept of a schema for plist files doesn’t exist as far as I’m aware, outside of how apps choose to serialize objects, that is. (The data structures an app uses could be considered a schema for a plist but it assumes the data structures themselves are versioned when they need breaking changes…)
https://developer.apple.com/library/archive/documentation/Ge... has an example of “stringly-typed” keys and values. There’s not much validation in a generic plist editor just as there isn’t validation in JSON or XML by default, but any app can add its own validation to ensure what it saves to a plist is something it can read later… that’s where the confusion over objects and codables comes in. If an app wrote the object to a part of a plist, it can thus de-serialize it from how it wrote it. If your app doesn’t understand another app’s plist, that’s pretty normal for complicated files or data kept by third-party apps. Few apps consider metadata and longevity when they write to disk, such that migrations are handled version to version as they need to, etc.
Xcode has aged very poorly and Apple top-level management refuses to invest further headcount into improving it in general.
They should port their custom tools like IB, view debugger, etc. over to Visual Studio Code and get out of the IDE game.
They should port their custom tools like IB, view debugger, etc. over to Visual Studio Code and get out of the IDE game.
> However being the maintainer of a build system means that sometimes people tell you things. Those things may be false or fabricated, of course, so the following is just speculation. I certainly have no proof for any of it. Anyhow it seems that a lot the fundamental code that is used to build macOS exists only in Xcode projects created ages ago. The authors of said projects have since left the company and nobody touches those projects for fear of breaking things. If true this would indicate that the Xcode development team has to keep those old versions working. No matter what.
> you need to replace every backslash with eight backslashes and then it will work.
Eight? Eight?
Good Lord.
Eight? Eight?
Good Lord.
Well, it grows exponentially.
You want to end up with one backslash `\`. After one escape, you get `\\`. If you escape the escaped string, you get `\\\\`. After another layer, you get `\\\\\\\\` for a single backslash.
Here's a somewhat realistic example: You need a piece of javascript in a string literal, and you need that javascript to generate a regex matcher for a single backslash. You could do that like this:
let code = "new RegExp(\"\\\\\\\\\")";
It's not _that_ uncommon when you need to marshal one language through many layers of languages (in my example, the regex language being marshalled through a javascript string literal and then another layer of javascript string literal). In XCode's case, two layers are obvious; you want a backslash, so you need the string which is fed to the shell to contain `\\`, so your XCode string literal has to be `"\\\\"`. For some unknown reason, there's a third level of escapes which takes us to `"\\\\\\\\"`.
You want to end up with one backslash `\`. After one escape, you get `\\`. If you escape the escaped string, you get `\\\\`. After another layer, you get `\\\\\\\\` for a single backslash.
Here's a somewhat realistic example: You need a piece of javascript in a string literal, and you need that javascript to generate a regex matcher for a single backslash. You could do that like this:
let code = "new RegExp(\"\\\\\\\\\")";
It's not _that_ uncommon when you need to marshal one language through many layers of languages (in my example, the regex language being marshalled through a javascript string literal and then another layer of javascript string literal). In XCode's case, two layers are obvious; you want a backslash, so you need the string which is fed to the shell to contain `\\`, so your XCode string literal has to be `"\\\\"`. For some unknown reason, there's a third level of escapes which takes us to `"\\\\\\\\"`.
On my job we used custom Xcode file parser / editor, and serialisation part is trivial. The file paths are not modified manually in any way. The complex part is the model, PBXProj object.
Pro-tip: in your model you can serialise Xcode project as XML format (that is, PLIST v2) and Xcode will correctly parse it. By default it uses PLIST v1, which looks like JSON, but differs in some things. I used standard 'description' obj-c call to produce PLIST v1, maybe there's another way to do it I don't know about.
Apple's dev tools are a huge liability for the company, basically the corporate equivalent of a superfund site. Sooner or later they'll have to address the issue and rewrite the whole thing from scratch, but by the time they do, it may be too late. The only thing that can compel them to fix it is an competitor eating into their market share, and once there is a better alternative, I think people may switch en masse. Mobile apps are mostly just some UI on top of an API, so switching everything to a new OS should be trivial.
It would be pretty hard to do all of that on purpose, let alone by accident, or by gradual accretion of new features. They must have worked really hard on that mess.
So it’s just a legacy file format that (as reflected in the article) has likely evolved from an internal object representation in the early days of macOS X (maybe earlier?).
Apple has been working on the tooling for the past several years. They improved the editor performance, created a new build system (llb), made a native dependency manager (swiftpm). For third-party tools they have released an LSP extension (hopefully they’ll end up using it internally in Xcode).
Apple has been working on the tooling for the past several years. They improved the editor performance, created a new build system (llb), made a native dependency manager (swiftpm). For third-party tools they have released an LSP extension (hopefully they’ll end up using it internally in Xcode).
> maybe earlier?
Yes, XCode originates from NeXTSTEP’s Project Builder: https://en.wikipedia.org/wiki/Project_Builder
Yes, XCode originates from NeXTSTEP’s Project Builder: https://en.wikipedia.org/wiki/Project_Builder
Only in spirit. NeXTStep's ProjectBuilder was GNU Make based, and IIRC it directly edited Makefiles (restricted subset of make - and you weren't supposed to touch them by hand) and also had a PB.project file that contained some limited metadata.
What became Xcode started out life as "Project Builder" (with a space), which was where the pbxproj file format was introduced. This debuted with Mac OS X (possibly circa DP4?) and was a ground-up rewrite - new UI, new project format, new build system (originally it used Jam, a little-known build system created by Perforce, before switching to something custom... IIRC it would generate an ephemeral Jamfile at build time).
For a while both could be installed on the same system - you needed ye olde NeXT ProjectBuilder for WebObjects 4.5 projects, and it was known as ProjectBuilderWO on Mac OS X for a while as a result.
What became Xcode started out life as "Project Builder" (with a space), which was where the pbxproj file format was introduced. This debuted with Mac OS X (possibly circa DP4?) and was a ground-up rewrite - new UI, new project format, new build system (originally it used Jam, a little-known build system created by Perforce, before switching to something custom... IIRC it would generate an ephemeral Jamfile at build time).
For a while both could be installed on the same system - you needed ye olde NeXT ProjectBuilder for WebObjects 4.5 projects, and it was known as ProjectBuilderWO on Mac OS X for a while as a result.
This is correct. The format was really nice during the NeXTStep era. It was an simple ASCII plist file called PB.project. It could be edited by a human.
When Apple started "improving" stuff it turned into the SomeProject.pbproj/project.pbxproj file and was not editable by a human. This file would later become SomeProject.xcode/project.pbxproj and then SomeProject.xcodeproj/project.pbxproj all the while getting worse and worse and less editable and less readable/understandable.
Here is the entire project file (PB.project) for IORegistryExplorer from Mac OS X 10.0
When Apple started "improving" stuff it turned into the SomeProject.pbproj/project.pbxproj file and was not editable by a human. This file would later become SomeProject.xcode/project.pbxproj and then SomeProject.xcodeproj/project.pbxproj all the while getting worse and worse and less editable and less readable/understandable.
Here is the entire project file (PB.project) for IORegistryExplorer from Mac OS X 10.0
{
APPCLASS = NSApplication;
DYNAMIC_CODE_GEN = YES;
English_RESOURCES = {};
FILESTABLE = {
CLASSES = (
RExplorer.m,
"RExplorer-OutlineDelegate.m",
"RExplorer-BrowserDelegate.m",
CustomOutlineView.m,
RSearch.m,
RBool.m
);
English_INTERFACES = (IORegistryExplorer.nib);
FRAMEWORKS = (AppKit.framework, Foundation.framework, IOKit.framework, System.framework);
FRAMEWORKSEARCH = ();
H_FILES = (
RExplorer.h,
CustomOutlineView.h,
"RExplorer-OutlineDelegate.h",
"RExplorer-BrowserDelegate.h",
RSearch.h,
RBool.h
);
IMAGES = (IORE.tiff);
INTERFACES = ();
OTHER_LINKED = (IORegistryExplorer_main.m);
OTHER_RESOURCES = (IORE.icns);
OTHER_SOURCES = (Makefile.preamble, Makefile, Makefile.postamble, CustomInfo.plist);
SUBPROJECTS = ();
};
LANGUAGE = English;
MAKEFILEDIR = "$(MAKEFILEPATH)/pb_makefiles";
NEXTSTEP_APPICON = IORE.tiff;
NEXTSTEP_BUILDTOOL = /bin/gnumake;
NEXTSTEP_DOCUMENTEXTENSIONS = ();
NEXTSTEP_INSTALLDIR = "$(SYSTEM_DEVELOPER_APPS_DIR)";
NEXTSTEP_JAVA_COMPILER = /usr/bin/javac;
NEXTSTEP_MAINNIB = IORegistryExplorer.nib;
NEXTSTEP_OBJCPLUS_COMPILER = /usr/bin/cc;
PDO_UNIX_BUILDTOOL = $NEXT_ROOT/Developer/bin/make;
PDO_UNIX_INSTALLDIR = /Applications;
PDO_UNIX_JAVA_COMPILER = "$(JDKBINDIR)/javac";
PDO_UNIX_OBJCPLUS_COMPILER = "$(NEXTDEV_BIN)/gcc";
PROJECTNAME = IORegistryExplorer;
PROJECTTYPE = Application;
PROJECTVERSION = 2.8;
WINDOWS_BUILDTOOL = $NEXT_ROOT/Developer/Executables/make;
WINDOWS_INSTALLDIR = /Applications;
WINDOWS_JAVA_COMPILER = "$(JDKBINDIR)/javac.exe";
WINDOWS_MAINNIB = "IORegistryExplorer-windows.nib";
WINDOWS_OBJCPLUS_COMPILER = "$(DEVDIR)/gcc";
}
It didn’t scale to large projects, though.
I get even better joy creating CMake files, they just work.
There is some “hope” with Swift...
Just as SwiftUI has allowed me to ditch endless awful Apple UI file formats, Swift Packages are a relatively simple way to avoid much of what might otherwise require the rest of Xcode to configure.
I feel like there may be an internal tug of war happening in Apple but I sincerely hope the people advocating for damn-near-undiffable file formats will lose.
Just as SwiftUI has allowed me to ditch endless awful Apple UI file formats, Swift Packages are a relatively simple way to avoid much of what might otherwise require the rest of Xcode to configure.
I feel like there may be an internal tug of war happening in Apple but I sincerely hope the people advocating for damn-near-undiffable file formats will lose.
> Just as SwiftUI has allowed me to ditch endless awful Apple UI file formats
I’ve not used storyboards/xib in years, in both objc and swift.
I’ve not used storyboards/xib in years, in both objc and swift.
Is it practically possible to create GUI application for MacOS without using XCode?
I am building my Sciter using premake5 on Win/Lin/rPI/Mac.
Premake5 is very useful to generate projects and makes for different platforms/IDEs. But on Mac premake5 is really works to create .dylibs only - seems like to generate GUI app on Mac XCode is the only option, is it?
I am building my Sciter using premake5 on Win/Lin/rPI/Mac.
Premake5 is very useful to generate projects and makes for different platforms/IDEs. But on Mac premake5 is really works to create .dylibs only - seems like to generate GUI app on Mac XCode is the only option, is it?
Depends on what "practical" means to you. For example, you can paste
import AppKit
_ = NSApplication.shared
NSApp.setActivationPolicy(.regular)
let window = NSWindow(contentRect: NSRect(origin: .zero, size: CGSize(width: 500, height: 500)), styleMask: [.titled, .closable, .miniaturizable, .resizable], backing: .buffered, defer: true)
window.title = "Test"
window.center()
window.makeKeyAndOrderFront(nil)
NSApp.activate(ignoringOtherApps: true)
NSApp.run()
It's very possible, check out code for glfw, sdl, and sokol and grep for "cocoa", "mac", but you do need ObjC, which can be written in C files with -ObjC flag.
Sometimes Xcode opens files on my computer like Json and XML as a default. I just know that everytime I accidentally open a file, I’m screaming to myself inside, “No, no” as the splash screen begins loading. I also find Xcode as my forcing factor to keep upgrading MacOS.
You should probably change the file associations for those to something else.
I only used Xcode a handful of times, so bear that in mind, but out of those handful of experiences it reminded me all of Metrowerks days in a bad way and if almost nothing has changed... decades since.
Every developer in my company unanimously hates Xcode, and we only use it if a client explicitly insists on an iOS app. Otherwise, it's PWAs all the way for 99% of use cases.
Users prefer PWAs too.
Out of curiosity, what do they like to use for development? Over the years I used numerous IDEs, and for me Xcode was the least problematic. None was great.
Some of my devs use Eclipse, some VSCode, some Atom, some Vim; it really varies. Sometimes, they'll use one for a particular language, and switch to another for a different language. I think every editor/IDE has its flaws, but all my devs unanimously seem to hate XCode.
Yep, the pbxproj format sucks. The good news is that each version of Xcode adds more power to the Swift Package Manager manifest file.
Apple's tooling peaked while it was still OpenStep. It's been a sharp downhill ride since then.
I like swift and swiftui.. I get it’s not cross platform but my apps are simple.
> You know, I really wish this file was XML instead.
Enough said. Xcode is the worst devtool I ever used
Enough said. Xcode is the worst devtool I ever used
And Apple keep bolting stuff on to it (and the new stuff doesn't work - Canvas for SwiftUI previews for example).
It's slow, broken in numerous ways, depends on file formats that aren't used anywhere outside of Apple and completely undocumented. It is such a painful tool to use.