Pitfalls of Using Cursor for iOS Development
#iOS App Development
1. Managing XCAssets
Basically, the XCAssets catalog is a bunch of directories with asset files and Contents.json
configs with all properties. The problem is that VSCode/Cursor doesn't know how to handle them.
Solution: Use Xcode
The only solution I found is to keep an Xcode running and CMD + Tab
into it when editing assets is needed.
Luckily, autocomplete for assets works fine in VSCode/Cursor.
2.Managing LocalizableStrings
If localized strings are stored in *.strings
files, that works fine. Strings are barely manageable when *.stringsdict
files are used.
I haven't tried using the Xcode strings catalog in VSCode/Cursor, but I expect the only way to handle it right now is to use Xcode.
3. Managing files of *.xcodeproj
When we add new files to the project Xcode makes sure that the *.xcodeproj
is updated to include them in the right target and handle them properly depending on the file type.
Cursor/VSCode does not.
For now, it seems like Xcode is still the king for handling project configs.
Adding new *.swift
files can be fixed in a few ways:
Option 1: Modularize the project with SPM packages
If the project itself is thin and all code is moved to local SPM packages there is no need to keep track of all files in *.xcodeproj
.
Option 2: Use Tuist
Tuist makes the *.xcodeproj
obsolete by generating it on the fly, based on the actual files.
Sweetpad has a setting that allows it to watch new .swift
files and runs Tuist autogenerate.
Option 3: Use XcodeGen
The same solution as Tuist
Option 4: Use Xcodeproj Gem
Xcodeproj lets you create and modify Xcode projects from Ruby. Script boring management tasks or build Xcode-friendly libraries. Also includes support for Xcode workspaces (.xcworkspace
), configuration files (.xcconfig
), and Xcode Scheme files (.xcscheme
).
So the solution could be:
More details: [[Cursor. Script to Add Files to Xcode Project]]
Option 5: Use Xcode
Keep Xcode open and use CMD+Tab
to switch to it whenever a new file needs to be created. Weird, but why not?
Comments