[HN Gopher] The joys of creating Xcode project files
___________________________________________________________________
The joys of creating Xcode project files
Author : ingve
Score : 128 points
Date : 2021-04-25 12:33 UTC (10 hours ago)
(HTM) web link (nibblestew.blogspot.com)
(TXT) w3m dump (nibblestew.blogspot.com)
| catchmeifyoucan wrote:
| 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.
| blumomo wrote:
| 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
| oauea wrote:
| 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.
| blumomo wrote:
| 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.
| NateEag wrote:
| 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.
| matchbok wrote:
| 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
| quux wrote:
| 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/
| aaronbrethorst wrote:
| 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
| flohofwoe wrote:
| 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.
| Turing_Machine wrote:
| > you need to replace every backslash with eight backslashes and
| then it will work.
|
| Eight? _Eight_?
|
| Good Lord.
| mort96 wrote:
| 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 `"\\\\\\\\\\\\\\\"`.
| viktorcode wrote:
| 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.
| c-smile wrote:
| 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?
| AJRF wrote:
| 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.
|
| 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.
| OnlyMortal wrote:
| 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.
| azinman2 wrote:
| 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).
| nexuist wrote:
| > 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).
| jcelerier wrote:
| > 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
| plorkyeran wrote:
| 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.
| adrusi wrote:
| Multiple tools doesn't mean that they can't interoperate.
| It's just that Apple (and everyone else) has given up on
| graphical IPC.
| colejohnson66 wrote:
| What's a graphical IPC? How would processes communicate
| graphically?
| nexuist wrote:
| 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.
| adrusi wrote:
| 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.
| adrusi wrote:
| 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.
| nexuist wrote:
| +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!).
| adrusi wrote:
| 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.
| yashap wrote:
| 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.
| MobileVet wrote:
| 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...
| anaerobicover wrote:
| You might also like https://xcodereleases.com/ which is
| updated automatically.
| AJRF wrote:
| 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.
| domano wrote:
| And they tax the CPU pretty hard too.
| MobileVet wrote:
| 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.
| smoldesu wrote:
| Xcode is ludicrously large. Most installs will clock in 50-60
| gigs, but I've seen more full setups exceed 100gb.
|
| Why is this the current paradigm of developing on a platform
| that notoriously "just works"?
| Cloudef wrote:
| 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.
| nexuist wrote:
| 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/
| Cloudef wrote:
| 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 ...
| FlashBlaze wrote:
| 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.
| Cloudef wrote:
| 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.
| smoldesu wrote:
| 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.
| wsc981 wrote:
| _> 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 LOVE 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.
| ASalazarMX wrote:
| It's the only IDE I've used where I couldn't trust it not to
| crash. IDEs should not crash, even if rarely.
| kitsunesoba wrote:
| 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.
| jamil7 wrote:
| 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.
| void_mint wrote:
| > 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.
| smoldesu wrote:
| I would almost be compelled to use and develop for Apple
| products if Xcode wasn't so comedically bad.
| fishywang wrote:
| 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.
| viktorcode wrote:
| 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.
| SoiGubz wrote:
| Apple's tooling peaked while it was still OpenStep. It's been a
| sharp downhill ride since then.
| mrlonglong wrote:
| I get even better joy creating CMake files, they just work.
| osrec wrote:
| 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.
| viktorcode wrote:
| 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.
| osrec wrote:
| 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.
| tersers wrote:
| Hasn't been updated in a while, but "Texts from Xcode"
| (https://www.textfromxcode.com/) has some fun collections of
| frustrations.
| [deleted]
| mistahenry wrote:
| 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
| lstamour wrote:
| 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
| fiddlerwoaroof wrote:
| 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...
| setpatchaddress wrote:
| 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.
| fiddlerwoaroof wrote:
| 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.
| Keyframe wrote:
| 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.
| orf wrote:
| > 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.
| mayoff wrote:
| Yep, the pbxproj format sucks. The good news is that each version
| of Xcode adds more power to the Swift Package Manager manifest
| file.
| fredrikholm wrote:
| 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).
|
| I work as a consultant, and often have to learn new
| languages/runtimes for my job, but nothing has been as bad as
| iOS.
| dalemyers wrote:
| 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.
| reaperducer wrote:
| _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.
| dalemyers wrote:
| 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.
| Apocryphon wrote:
| It could certainly be mitigated if the creator of the
| software published less opaque documentation about it.
| dalemyers wrote:
| 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.
| xbar wrote:
| 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.
| dalemyers wrote:
| 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.
| ASalazarMX wrote:
| 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.
| Cloudef wrote:
| 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.
| bartvk wrote:
| 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.
| makecheck wrote:
| 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.
| db48x wrote:
| 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.
| ajconway wrote:
| 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).
| rmorey wrote:
| > maybe earlier?
|
| Yes, XCode originates from NeXTSTEP's Project Builder:
| https://en.wikipedia.org/wiki/Project_Builder
| agsnu wrote:
| 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.
| eddieh wrote:
| 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 {
| 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"; }
|
| Simple. Elegant. Usable.
| setpatchaddress wrote:
| It didn't scale to large projects, though.
___________________________________________________________________
(page generated 2021-04-25 23:01 UTC)