This is similar to this issue:
Error in Sandboxed App, When loading Helper (LoginItems), code signing issue
The error that I'm getting is the same, but installing the app in /Applications doesn't fix the problem because since SMLoginItemSetEnabled only allows you to set an app bundle id and not the actual app location, it always ends up trying to load some other copy of the helper app that is not in /Applications. Theoretically I could delete all copies of the App on my computer and that should fix the problem, but I cannot prevent users from keeping multiple copies of my app on their computer, which would break the launch at login feature.
Is there a way around this?
Bump the version number of the instance of the login item that you want to be launched. If it's the highest version number, the system should prefer it to existing lower versions of the login item.
If multiple applications (for example, several applications from the same company) contain a helper application with the same bundle identifier, only the one with the greatest bundle version number is launched. Any of the applications that contain a copy of the helper application can enable and disable it.
https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLoginItems.html#//apple_ref/doc/uid/10000172i-SW5-SW1
Related
I have been developing my first SWIFT MacOS App and it uses Core Data. I've just done my first release build and found that it still points at the same SQL Lite DB as my debug build. As I didn't not specify it's location I assumed (incorrectly) it would be in a different location for release.
How do I specify the location of the Database for Core Data ? Is there a way to automatically set a different location for Debug and Release ? I want to be able to run release and debug on the same machine.
What I usually do is have separate debug and release versions of the app. Then I can have both installed on the same device at the same time. The persistent store (and other files) use the same file names, but since they're separate apps the data is separate.
You can do this by duplicating the app target in Xcode, and making a few changes. In the list of targets, right-click your app and select "duplicate". Give the new one a similar but slightly different name. For example, maybe add "-dev" to your app's name to indicate it's the development target.
You'll also need to change the bundle ID and display name of the app. The bundle ID tells iOS it's a different app, and the display name makes it obvious which one you're tapping. You can also add a different app icon if you like.
Now you can build two versions of the app and install both on the same device. The dev version can have whatever code you're working on that's maybe still kind of broken, and the release version can be whatever's ready for release or a version downloaded from the App Store.
In iOS, your CoreData database file is usually located in Library/Application Support within the sandboxed App. Pre iOS 10 it used to be in the Documents folder.
On MacOS with sandboxing enabled it's usually located at ~/Library/Containers/<app_bundle_id>/Data/Library/Application Support/<app_target_name>
Depending on your needs, you can choose different locations for each of your persistent stores when you setup the CoreData stack.
However, I don't see any reason to choose different store locations for different Build Configurations. Thats not the purpose for Build Configurations anyway. Your database will end up being exactly the same - it cannot be affected by build settings.
I would also not recommend to use different store locations for any purpose - except perhaps when you perform Unit Tests.
What you can do however, is to set certain environment flags that affect CoreData's behaviour, for example that enables Thread Violation Assertions. You do this in Xcode Schemes - not in the build settings. Note, that a scheme uses a certain Build Configuration, say Release or Debug and that the name for the scheme can be the same which is often confusing.
You should ensure that these helpful assertions that you can set in a Scheme are not enabled when you build a release. ;)
I have an application already on the store and would like to release an update. Since my app deals with databases and I've had to change some parts of it, I would like to ensure that the update does not affect the existing functionality in any way once the user updates from the App Store.
What I did was this - install the first version of my app on my device. Changed the update's version in info.plist to 1.1 and run it via xcode (and install on my device). But what happens by doing this is some of the changes I made to the XIBs do not show up. It looks as if the app was only half-updated (if you know what I mean)
Is there any way to update an existing app programmatically without having to go through the app store and then find out it could lead to a disaster?!
Thanks for any help!
I would double check your build configuration. Between building the two versions of the app, I would recommend a "Clean All" just to be safe. The process you described works to verify updates. The only other alternative I can come up with is to create Ad-hoc distributions of both versions of your app, and install those.
I have two versions of my app. I'm trying to keep a copy of each on my iPhone for testing purposes.
In my build settings, my bundle display name is ${PRODUCT_NAME} and I've given each version of my app a different product name (eg "v92" and "v10"). When I install each version to my iPhone, they both appear side by side with different names, however one will work normally, and the other will immediately close the moment it's opened. If I delete the version that works normally, the other will start working.
Does anyone know what's going on?
I think the apps are distinguished on the device by the App Id and not the product name. I dont know how you were able to install two apps only by changing the product name. When i mistakenly installed a different app with same app id but different product name the original app was overwritten.
Try creating a separate app id for the new version only for testing. That might solve your problem but make sure you use the correct app id when you submit your app.
EDIT: It might not be the right solution if you are doing some app id specific stuff (like APNS) in you app.
I ran into this one too and eventually solved it. I know the solution had to do with changing something in the information property list, but I'm not sure exactly what. I would suggest making sure that all of the following are different for your two versions:
bundle display name
executable file
bundle identifier
bundle name
At least you can create two app id's and two provisioning profiles in your developers account. Then you'll be able to install your 2 versions like a two different apps. It's an ugly solution, but it definitely works.
Hi have noticed today whilst writing a simple iPhone app that Xcode sometimes starts a new folder in applications, whilst your still working on the same app.
/Users/Fuzzygoat/Library/Application Support/iPhone Simulator/User/Applications/4E5EF4F0-F410-46A6-888C-0D23BB97D2DC
Does anyone know what causes Xcode to swap to a new app folder (i.e. the one named "4E5EF4F0-F410-46A6-888C-0D23BB97D2DC")
EDIT_001: One thing I have noticed is that I have been doing a lot of quitting an application and restarting to check a set of archive methods, and that does tend to confuse it sometimes. A couple of times it has not found saved data, I guess this is just a side effect of constantly running the simulator over and over via Xcode. Things seem to go just fine if I test on the Simulator without Xcode, for a start the folder keeps the same name.
NB: I am using NSSearchPathForDirectoriesInDomains to get the documents folder each time.
gary
For security reasons, iPhone OS restricts an application (including its preferences and data) to a unique location in the file system. This restriction is part of the security feature known as the application’s “sandbox.” The sandbox is a set of fine-grained controls limiting an application’s access to files, preferences, network resources, hardware, and so on. In iPhone OS, an application and its data reside in a secure location that no other application can access. When an application is installed, the system computes a unique opaque identifier for the application. Using a root application directory and this identifier, the system constructs a path to the application’s home directory. Thus an application’s home directory could be depicted as having the following structure:
/ApplicationRoot/ApplicationID/
During the installation process, the system creates the application’s home directory and several key subdirectories, configures the application sandbox, and copies the application bundle to the home directory. The use of a unique location for each application and its data simplifies backup-and-restore operations, application updates, and uninstallation. For more information about the application-specific directories created for each application and about application updates and backup-and-restore operations.
see The Application Sandbox
I know it happens when you restart the simulator. At least, that is when I have definitely observed it.
The developer docs tell you that the path can change without warning and to never depend on it. This is part of the iPhone's security system which prevents malicious apps from using hardcoded paths to find and exploit system resources.
I was just making a free version of one of my apps. I copied the folder, renamed the project, and changed the icon file, loading screen, interface, and code. BUT YET it still replaces a build on my phone.
1)how do I stop this from happening (i want both the free and paid version on my phone)
2) if you can fix this, will a customer who has the paid, and downloads the free, will that replace it on their phone?
I really need to know these, as I have the app ready to go, and would like to get it before the end of the week.
cheers
Sam
You need to have a different app bundle identifier. I think that's your problem.
Long answer:
Go into your projectname-info.plist file and change the CFBundleIdentifier.
I'd recommend something like:
com.mycompany.mycoolapp for the app store
com.mycompany.mycoolapp-beta for the beta version
You should actually be able to set up the "Debug" build configuration to use a different info.plist file configured with a different CFBundleIdentifier and a different icon filename. That way you'll automaticlly get the beta ID and icon, etc for the Debug build and the real id/icon for the full one.
This should allow users to install and use both the production and test versions of the apps at the same time without confusion.
You might also find this IPA target template helpful if you're doing ad-hoc distribution to Windows users for testing:
http://devblog.appmagination.com/2010/01/target-template-for-building-iphone-ipa.html