Git ignore file for Xcode projects

Question

Which files should I include in .gitignore when using Git in conjunction with Xcode?

Solution 1

I was previously using the top-voted answer, but it needs a bit of cleanup, so here it is redone for Xcode 4, with some improvements.

I've researched every file in this list, but several of them do not exist in Apple's official Xcode documentation, so I had to go on Apple mailing lists.

Apple continues to add undocumented files, potentially corrupting our live projects. This IMHO is unacceptable, and I've now started logging bugs against it each time they do so. I know they don't care, but maybe it'll shame one of them into treating developers more fairly.

---

If you need to customize, here's a gist you can fork: https://gist.github.com/3786883

---

#########################
# .gitignore file for Xcode4 and Xcode5 Source projects
#
# Apple bugs, waiting for Apple to fix/respond:
#
#    15564624 - what does the xccheckout file in Xcode5 do? Where's the documentation?
#
# Version 2.6
# For latest version, see: http://stackoverflow.com/questions/49478/git-ignore-file-for-xcode-projects
#
# 2015 updates:
# - Fixed typo in "xccheckout" line - thanks to @lyck for pointing it out!
# - Fixed the .idea optional ignore. Thanks to @hashier for pointing this out
# - Finally added "xccheckout" to the ignore. Apple still refuses to answer support requests about this, but in practice it seems you should ignore it.
# - minor tweaks from Jona and Coeur (slightly more precise xc* filtering/names)
# 2014 updates:
# - appended non-standard items DISABLED by default (uncomment if you use those tools)
# - removed the edit that an SO.com moderator made without bothering to ask me
# - researched CocoaPods .lock more carefully, thanks to Gokhan Celiker
# 2013 updates:
# - fixed the broken "save personal Schemes"
# - added line-by-line explanations for EVERYTHING (some were missing)
#
# NB: if you are storing "built" products, this WILL NOT WORK,
# and you should use a different .gitignore (or none at all)
# This file is for SOURCE projects, where there are many extra
# files that we want to exclude
#
#########################

#####
# OS X temporary files that should never be committed
#
# c.f. http://www.westwind.com/reference/os-x/invisibles.html

.DS_Store

# c.f. http://www.westwind.com/reference/os-x/invisibles.html

.Trashes

# c.f. http://www.westwind.com/reference/os-x/invisibles.html

*.swp

#
# *.lock - this is used and abused by many editors for many different things.
#    For the main ones I use (e.g. Eclipse), it should be excluded
#    from source-control, but YMMV.
#   (lock files are usually local-only file-synchronization on the local FS that should NOT go in git)
# c.f. the "OPTIONAL" section at bottom though, for tool-specific variations!
#
# In particular, if you're using CocoaPods, you'll want to comment-out this line:
*.lock


#
# profile - REMOVED temporarily (on double-checking, I can't find it in OS X docs?)
#profile


####
# Xcode temporary files that should never be committed
# 
# NB: NIB/XIB files still exist even on Storyboard projects, so we want this...

*~.nib


####
# Xcode build files -
#
# NB: slash on the end, so we only remove the FOLDER, not any files that were badly named "DerivedData"

DerivedData/

# NB: slash on the end, so we only remove the FOLDER, not any files that were badly named "build"

build/


#####
# Xcode private settings (window sizes, bookmarks, breakpoints, custom executables, smart groups)
#
# This is complicated:
#
# SOMETIMES you need to put this file in version control.
# Apple designed it poorly - if you use "custom executables", they are
#  saved in this file.
# 99% of projects do NOT use those, so they do NOT want to version control this file.
#  ..but if you're in the 1%, comment out the line "*.pbxuser"

# .pbxuser: http://lists.apple.com/archives/xcode-users/2004/Jan/msg00193.html

*.pbxuser

# .mode1v3: http://lists.apple.com/archives/xcode-users/2007/Oct/msg00465.html

*.mode1v3

# .mode2v3: http://lists.apple.com/archives/xcode-users/2007/Oct/msg00465.html

*.mode2v3

# .perspectivev3: http://stackoverflow.com/questions/5223297/xcode-projects-what-is-a-perspectivev3-file

*.perspectivev3

#    NB: also, whitelist the default ones, some projects need to use these
!default.pbxuser
!default.mode1v3
!default.mode2v3
!default.perspectivev3


####
# Xcode 4 - semi-personal settings
#
# Apple Shared data that Apple put in the wrong folder
# c.f. http://stackoverflow.com/a/19260712/153422
#     FROM ANSWER: Apple says "don't ignore it"
#     FROM COMMENTS: Apple is wrong; Apple code is too buggy to trust; there are no known negative side-effects to ignoring Apple's unofficial advice and instead doing the thing that actively fixes bugs in Xcode
# Up to you, but ... current advice: ignore it.
*.xccheckout

#
#
# OPTION 1: ---------------------------------
#     throw away ALL personal settings (including custom schemes!
#     - unless they are "shared")
# As per build/ and DerivedData/, this ought to have a trailing slash
#
# NB: this is exclusive with OPTION 2 below
xcuserdata/

# OPTION 2: ---------------------------------
#     get rid of ALL personal settings, but KEEP SOME OF THEM
#     - NB: you must manually uncomment the bits you want to keep
#
# NB: this *requires* git v1.8.2 or above; you may need to upgrade to latest OS X,
#    or manually install git over the top of the OS X version
# NB: this is exclusive with OPTION 1 above
#
#xcuserdata/**/*

#     (requires option 2 above): Personal Schemes
#
#!xcuserdata/**/xcschemes/*

####
# Xcode 4 workspaces - more detailed
#
# Workspaces are important! They are a core feature of Xcode - don't exclude them :)
#
# Workspace layout is quite spammy. For reference:
#
# /(root)/
#   /(project-name).xcodeproj/
#     project.pbxproj
#     /project.xcworkspace/
#       contents.xcworkspacedata
#       /xcuserdata/
#         /(your name)/xcuserdatad/
#           UserInterfaceState.xcuserstate
#     /xcshareddata/
#       /xcschemes/
#         (shared scheme name).xcscheme
#     /xcuserdata/
#       /(your name)/xcuserdatad/
#         (private scheme).xcscheme
#         xcschememanagement.plist
#
#

####
# Xcode 4 - Deprecated classes
#
# Allegedly, if you manually "deprecate" your classes, they get moved here.
#
# We're using source-control, so this is a "feature" that we do not want!

*.moved-aside

####
# OPTIONAL: Some well-known tools that people use side-by-side with Xcode / iOS development
#
# NB: I'd rather not include these here, but gitignore's design is weak and doesn't allow
#     modular gitignore: you have to put EVERYTHING in one file.
#
# COCOAPODS:
#
# c.f. http://guides.cocoapods.org/using/using-cocoapods.html#what-is-a-podfilelock
# c.f. http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control
#
#!Podfile.lock
#
# RUBY:
#
# c.f. http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/
#
#!Gemfile.lock
#
# IDEA:
#
# c.f. https://www.jetbrains.com/objc/help/managing-projects-under-version-control.html?search=workspace.xml
# 
#.idea/workspace.xml
#
# TEXTMATE:
#
# -- UNVERIFIED: c.f. http://stackoverflow.com/a/50283/153422
#
#tm_build_errors

####
# UNKNOWN: recommended by others, but I can't discover what these files are
#

Solution 2

Based on this guide for Mercurial my .gitignore includes:

.DS_Store
*.swp
*~.nib

build/

*.pbxuser
*.perspective
*.perspectivev3

I've also chosen to include:

*.mode1v3
*.mode2v3

which, according to this Apple mailing list post, are "user-specific project settings".

And for Xcode 4:

xcuserdata

Solution 3

Regarding the 'build' directory exclusion -

If you place your build files in a different directory from your source, as I do, you don't have the folder in the tree to worry about.

This also makes life simpler for sharing your code, preventing bloated backups, and even when you have dependencies to other Xcode projects (while require the builds to be in the same directory as each other)

You can grab an up-to-date copy from the Github gist https://gist.github.com/708713

My current .gitignore file is

# Mac OS X
*.DS_Store

# Xcode
*.pbxuser
*.mode1v3
*.mode2v3
*.perspectivev3
*.xcuserstate
project.xcworkspace/
xcuserdata/

# Generated files
*.o
*.pyc


#Python modules
MANIFEST
dist/
build/

# Backup files
*~.nib

Solution 4

For Xcode 4 I also add:

YourProjectName.xcodeproj/xcuserdata/*
YourProjectName.xcodeproj/project.xcworkspace/xcuserdata/*

Solution 5

I included these suggestions in a Gist I created on Github: http://gist.github.com/137348

Feel free to fork it, and make it better.

View more solutions

Comments

[Lily Ballard]

I don't particularly like the .pbxuser/.perspective/*.perspectivev3 patterns. I much prefer the following .xcodeproj/ !*.xcodeproj/project.pbxproj That ignores everything inside a *.xcodeproj except the project.pbxproj.

[Berry Ligtermoet]

I do have the build folder outside of the project folder, but when other users build the project, it by default is recreated in the project- so I found that adding it to the ignore file is a better solution, otherwise it gets readded in their commits.

[Berry Ligtermoet]

I do not ignore *.pbxuser, *.perspective and *.perspectivev3 because I like to keep those settings back when I clone my repository.

[Jacob]

Use build/ to exclude only directories named build in case you might have a script or something named build that you don't want to ignore.

[Ryan McCuaig]

I like to leave in build/Release-iphoneos so I have a copy of every released device app I seed out to people. Patterns to add would be build/Debug-* and build/*-iphonesimulator .

[Mike Tyson]

I'm not sure if I'd keep this in my repository. Perhaps a better solution would be to keep your build folder outside of your project in some central location (e.g. /builds/projectname/**) and keep the /builds directory backed up with something like GetDropbox?

[Jess Bowers]

Also you might want to add that you can make a "global" gitignore file like this: git config --global core.excludesfile ~/.gitignore

[memmons]

I agree with Luke regarding his hesitation to keep the build directory version controlled in the same repository. In any case, if you often integrate external libraries and projects into your xcode projects, you should configure your build directory to be common anyway. I typically keep mine in /Users/Shared/<username>/Products

[ma11hew28]

If you just add xcuserdata, then that takes care of both.

[Deamon]

I'd like to caution everyone who added .gitignore file after they have committed the project: those files you ignore are still being tracked. You'll have to remove them from git manually using git rm --cached <files>

[Erik]

Using xcuserdata is bad as it prevents your xcschemes directory from being version controlled.

[curtisdf]

In Xcode 4, it appears that the only files to worry about are xcuserdata directories and .DS_Store, and the rest aren't needed in .gitignore. I have an active project that's never been opened in XCode 3, but only in v4, and none of the other files were present in my file hierarchy. It uses Storyboard instead of .xib's for the views. My config is normal too, i.e. no "weird" customizations like moving the build directory from its default location.

[Christoph]

According to stackoverflow.com/a/9552687/599884 and github.com/github/gitignore/blob/master/Objective-C.gitignor‌​e it seems to be a good idea to also ignore xcworkspace

[SpacyRicochet]

The comment @KevinBallard is extremely useful, except that it contains a small oversight. *.xcworkspace/* !*.xcworkspace/ !*.xcworkspace/contents.xcworkspacedata works, since it first blacklists every file in the project folder, then whitelists the folder itself and then whitelist the project file. This way, the entire folder will not be blacklisted, which causes git to skip it entirely.

[Lily Ballard]

@SpacyRicochet: Comment formatting has apparently changed since I wrote the comment. Hence the italics. My pattern is supposed to look like *.xcodeproj/* !*.xcodeproj/project.pbxproj. Of course, these days you do need to adjust it for workspaces.

[hakre]

Did you add it also? Or is this just all you do?

[Adam]

I assumed you meant a gist - seeing as the official github project for .gitignores was unmaintained and refusing submissions last time I looked (IIRC there were 200 ignored pull requests, and a huge number of Issues that were being ignored)

[user1524957]

Yes, I added both but xcusersate was the main offending file. Adding that was the only way I could push my code remotely. Otherwise I was stuck in a feedback loop that required commit before push. So you commit, then Xcode 4.5 would ask you to commit again and you are never able to push because the pre req is committing.

[Adam]

This has already been posted to one of the answers above. I found it to be: incorrect, questionably supported (more than 100 outstanding pull requests!), and undocumented. The fact that it's "incorrect" is the worst of all; they have made an ignore that only works for a narrow set of uses and haven't explained what or why! Hence: my answer above, which corrects their bugs AND explains what's being done and why, so you can make educated decisions on a project-by-project basis (on a new project, I sometimes forget why some of the items are in there - the comments help me decide :))

[samson]

Ok, I just noticed a problem with this. I was doing some git acrobatics, and when I checkout out back to master and applied my stashed changes, I had lost my saved build schemes! fortunately, I had backed them up, just in case... but the solution is to ignore a little more specifically inside the xcuserdata directory. I changed xcuserdata to xcdebugger and UserInterfaceState.xcuserstate, which are really the offensive ones to commit.

[Michael Kessler]

I also suggest to add .svn for projects that work with both source control systems

[Adam]

@samson - " I had lost my saved build schemes! " -- argh! That's what I was trying to avoid! Sorry :(. I've added an exception for "xcschemes" which seems to be what my Xcode is using

[Adam]

@MichaelKessler I can see that helping for some projects, but using one project with two SCM's sounds very unusual (dangerous in many ways). I've been on projects where we did it deliberately - but 9 times in 10 when I've seen it, it was an accident. In most cases, I think it's a major bug / mistake to have two SCM's versioning one set of files, so I'd rather leave the .svn folder in there -- for most people, they'll see all the .svn files appear and go "WTF?" and realise their mistake.

[Michael Kessler]

@Adam, In general you are right - there is almost no reason to work with 2 SCMs on one project. But I have personally used this approach several times. The most common (for me) case was when a client gives me his existing project with SVN. I work with GIT. I think that there was no project where SVN worked 100% well for me - there are always problems with it. This is why I always create my own git repository for all the ongoing commits and ignore the .svn folders. Eventually I commit all the changes to client's SVN and forget about it.

[cannyboy]

I added cocoapods to the mix

[tvon]

You shouldn't be ignoring *.lock or Podfile.lock (never mind the redundancy). You want the exact same versions installed in all workspaces, you don't want the "latest version".

[Adam]

I have removed the Podfile part. I didn't add that originally, SO says someone else added it and I carelessly copy/pasted it into the gist. My apologies for any/all confusion and misunderstanding. I really dislike the way StackOverflow lets anyone edit your answers :(.

[tvon]

@Adam Thanks, though the *.lock line will still cause problems. If you are using bundler then a Gemfile.lock is important (and I'm not sure what that line is trying to do anyway, I've never had random .lock files show up).

[Adam]

There's now an explanation line for EVERYTHING, line by line. This should make it much clearer, and make it easier to customize for your own projects.

[Ricardo Sanchez-Saez]

@Adam: Thanks for this! Notice that the gist link still points to v2.0 instead of v2.1.

[Adam]

@skywinder - do you have a reference to Xcode docs on this? Ideally a URL to a paragraph in Apple's docs that states what xccheckout files contain. I'm being hyper-cautious about adding more files to gitignore - one mistake, and we could cause someone to lose their important work!

[skywinder]

@Adam As I can see, this file contains VCS metadata, and should therefore not be checked into the VCS. No, there no mentions on developer.apple.com about xccheckout. But on official github page, this file included already in the gitignore file. https://github.com/github/gitignore/blob/master/Objective-C.‌​gitignore

[BastiBen]

For some reason just adding xcuserdata without the prefix didn't work for me. I thought it should, though. Odd.

[Adam]

@skywinder According to this answer on SO you may be wrong: stackoverflow.com/a/19260712/153422 - that file is important. I will NOT ignore files until you can prove they are irrelevant - if we get it wrong, the damage is great. The "official github page" IS CONSISTENTLY WRONG (you really shouldn't use it), and is definitely NOT an argument for doing it right!

[Adam]

6 weeks later, and Apple still hasn't replied to my request for docs on "what" xccheckout file contains :(. I guess we won't be getting any docs.

[Adam]

Update: It's been 4 months and ... Apple still hasn't responded to the bug report. Recommendation: don't file bug reports with Apple, it's a waste of your time :(

[Mano]

i have added all the above code in .gitignore file.. still i get the same error "uncommited changes" with the file UserInterfaceState.xcuserstate

[Adam]

@ManojEllappan If you've previously committed a file, Git will "ignore the ignore" and continue to track it (this is a slightly annoying feature of git). There's SO.com answers on how to fix this, look for "remove ignored files from git" or similar.

[Adam]

NB: current version has some improvemetns and more "optional" features. TODAY we can safely add CocoaPods and Ruby, even for people that don't use them - but I don't want to add sections for every non-Apple programming language just because "someone might" use it - if you're using non-Apple tools with Xcode, that's your responsibility. But we CAN make it easier for you: I've added an "optionals" section at bottom. Uncomment lines for your specific setup. BUT NOTE: this will be less-well tested than the main gitignore - use at own risk!

[Adam]

ALSO: anyone else that is regularly using non-Apple tools with Xcode, and has ignore lines to add - please add comments and/or comment on the GitHub gist, and I'll add them (commented out by default) to the OPTIONALS section. As always, I'll need a URL from you that has docs explaining why you want that change :)

[Nikolay Shubenkov]

always use your example. nice settings! Thanks!

[Alex Zavatone]

Help me understand why we would be ignoring *.nib files please.

[Adam]

@AlexZavatone We're not. Look at that line carefully - there's an extra character. As per the comment above.

[Alex Zavatone]

Not understanding how the comment about xib and nib files is relevant to the *~.nib files. You just say "so we want this", you don't say what the *~.nib files are. I'm inferring that these are some type of temp file for a .nib file when the file is being saved. Am I correct here? What is a *~.nib file?

[Adam]

@AlexZavatone AFAIAA, *~.nib will, by (Apple's) definition, never match a NIB file, unless you happened to rename a NIB file to (from Apple's definition) an illegal name. This is all Apple standard stuff, if you googled tilde-filenames in OS X I'm sure you'd find lots of info.

[Alex Zavatone]

Yeah, I have looked for it. I've never seen it. What is it? Why would we have to ignore it? Simply, what is it? I've looked, trust me. Wasted too much time looking and Google doesn't return anything useful.

[crosscode]

The github .gitignore file is a collection of all files which we had problems with in the past. Right now, if you start a Xcode project from scratch an let Xcode preconfigure the git repository, there's not too much left to ignore in .gitignore: The only thing I prefer to ignore is xcuserdata/ ... this helps not to clutter your commits.

[Robert]

What about the .original files that file merge creates?

[Adam]

@robert - link? Happy to add if appropriate, but need primary evidence / official docs to reference in each case. I haven't seen .original before, maybe because using different workflow on merging?

[jcsahnwaldt Reinstate Monica]

@Adam a little typo: "xcsshareddata" should be "xcshareddata". Thanks for the great answer!

[Cœur]

@Adam xcuserdata should be xcuserdata/

[Adam]

@skywinder More than a year later, still no reply from Apple, and in practice the .xccheckout file seems to cause more harm than good (I've seen a few people get bitten by it). So I've added it to ignore, but with lengthy explanation. If anyone has a problem with this, please shout! I asked-around but no-one had had problems with ignoring it, so I believe it's safe to ignore.

[Adam]

@SteveSchwarcz I've not been doing much with Xcode6 (mostly maintenance updates of existing apps), but so far this gitignore has been working fine for me. If you have any specific issues/tweaks, please share links and I'll review them.

[skywinder]

@Adam Confirm! xccheckout is dummy and cause a lot of redundant changes in case of forking repo! Get rid of this!

[Eric]

@Adam: GitHub's .gitignore has now been updated for Xcode 6.3.2 and Swift, so it's now correct. It's also documented.

[Adam]

yeah, but the problem with publishing a data-destructive file and keeping it that way for months or years - and apparently not bothering to test it properly - is that you permanently sacrifice all faith, trust, respect from the community. Too late.

[hashier]

It's better to just ignore .idea/workspace.xml instead of the whole directory since you find a lot of project related settings in the .idea folder. For example code styling, shared search settings, code inspection settings, all of these should be shared within the team.

[Adam]

@hashier can you provide a link explaining that?

[hashier]

@adam It's mostly found out by testing and bits and pieces from the documentation. If you define coding styles or search paths and mark them as shared they end up in the .idea folder in respectively file names. If you don't mark them shared they are added to the workspace file. Here are two helpful links: jetbrains.com/objc/help/… and jetbrains.com/objc/help/… so apparently .idea/tasks.xml and some others should be excluded as well

[Lyck]

@adam I could only get xccheckout ignored in XCode by prefixing it with an asterisk - just like it's done in the last line of the file. The stuff about xccheckout at the bottom should really be removed or moved up to the place where it's ignored as the file is now - it's a duplicate.

[Adam]

@lyck thanks - I thought I'd already edited that out, but apparently I didn't hit save. Stupid mistake, my bad.

[Dave Wood]

@adam After seeing links like this: github.com/search?utf8=✓&q=filename%3Aid_rsa&type=Code&ref=s‌​earchresults I've started ignoring .ssh/* id_rsa* id_dsa* as well. Just to avoid accidental inclusion.

[foundry]

@Adam - your gist is still on v2.5, perhaps you should update (currently v2.6 here)

[Adam]

@scottyb - I haven't seen any problems yet, but Apple has probably added some additional files we need to consider carefully. Please be careful and if you notice any problems with xcode, check if there's files outside git that are unexpected

[Nate Chandler]

@Adam It'd be nice to get *.xcscmblueprint added to this document. ( stackoverflow.com/questions/31584297/… ) And thank you for maintaining such a useful document!

[Teddy]

This just drives me crazy. Breakpoints_v2.xcbkptlist still gets tracked and commited. Incredible annoying and I cannot do anything about it.

[Adam]

@Teddy - if you can find a URL to official page describing that file and its contents, or a 3rd party detailed investigation (so we can be 99% sure we've understood it correctly), I'll add some sections for it, and whatever variants there are.

[Teddy]

@Adam: I am not sure what you want from me. An example of "Breakpoints_v2.xcbkptlist" file? I can upload, no problem. But to be honest I do not understand why the content matters if I add *.xcbkptlist files to the ignore list. Should not it just skip the file completely regardless the content?

[Adam]

Without official description, we're not going to ignore anything. Almost every time people have done that, it's corrupted someone's project sooner or later. Way too dangerous - don't go there. So I refuse to add anything to this file unless I have a verifiable source confirming it is safe to ignore!

[Teddy]

OK, I got your point. The thing is that you have added it because it is under "xcuserdata/". Yet git tracks the file. All other files under xcuserdata are properly ignored except for the breakpoints file (breakpoints_v2 file contains information about the breakpoints you set up for debugging in Xcode). I do not understand why.

[Suragch]

Very useful answer. I added it as a link in my Setting Up Github in Xcode answer.

[Ky -]

GitHub is the first place I ever look for gitignores :)

[jpmc26]

I'm not sure duplicating the file that's stored on an actual source control hosting site is wise.

[SilverWolf]

Shouldn't you use *.sw? instead of *.swp? Vim will create multiple swap files for multiple concurrent editing sessions, and name them .swo, .swn, etc.

[Adam]

@user770 the file on that site is borderline malicious. Whoever committed it clearly either has NO IDEA what they're doing, or wants to mess up other people's projects. As I keep saying: DO. NOT. TAKE. RANDOM. INTERNET. GITIGNORES. FROM. IDIOTS. WHO. DON'T. EXPLAIN. EVERY. LINE!

[drew..]

Following most of these practices and yet i still occasionally get podfile out-of-sync issues between branches. So annoying. Makes me want to ignore the pod control files completely.

[Ashley Mills]

How is this any different to any of the previous answers? Don't just paste your gitignore file here, this does not add anything to this subject.

[Ashley Mills]

I haven't used gitignore.io for a while - worth checking if you haven't. You can use it to create a gitignore file for whatever IDE / language etc you're using. It'll even add a cocoapods section. Brilliant

[Rahul Singha Roy]

@AshleyMills Please read the answar first then add a comment .... The answar is for a standerd structure / required ones .... which are essentials to have ...

[Ely Dantas]

For the next person trying to install Joe, check if it's 5+ years of dead repo resurrected before wasting time

[Alwin Jose]

I studied this from youtube.com/watch?v=b0g-FJ5Zbb8 (14:50)

[Alwin Jose]

Note: Can replace Objective-C with swift, node, etc based on your requirement.

[Shahbaz Akram]

perfect with +1

[Mark]

-bash: npx: command not found

[Alwin Jose]

Please install node from nodejs.org/en If still didn't work, please run the command stated in stackoverflow.com/a/51224061/11844048

[GrayedFox]

@Adam "...but maybe it'll shame one of them into treating developers more fairly." - hope is the last to die eh? But in earnest: good on ya, we can only try!

[Dani]

Is this unchanged for SwiftUI?