I frequently find that I need to have a build on my iPhone which is my 'demo-ready' version which might point to my demo server. I also want a build that is the latest and greatest debug build that I'm developing with that points to my development server. Has anyone found a really simple way for me to install two apps that perhaps are the exact same code but point to different servers? Alternately perhaps I would have an app that was a few versions behind the latest version? Preferably I would use the same XCode project to build and install onto the iPhone.
You can add special build configurations for them that each use a different info.plist file. So, maybe for your demo, you have an info.plist named MyApp-Info-DEMO.plist and MyApp-Info.plist for the release.
Then you could add your server variable as an info.plist variable and look it up when the app starts. Or even just create a DEFINE statement in your new configuration that's something like SERVER=demo.myserver.com for the demo and SERVER=production.myserver.com for the live.
The most important part is to change the CFBundleIdentifier in the new info.plist. So in your demo, you could name it something like com.mycompany.myapp.DEMO and the real one might just be com.mycompany.myapp.
This will allow both versions to appear on the phone at the same time (the different CFBundleIdentifiers). Just remember, if you are using in-app purchases or server push notifications, you won't be able to do this without a separate, specific profile for both your real app identifier and your demo one.
You could create 2 different targets with 2 different info.plists and 2 different preprocessor defines (in the Build Settings for each of the 2 targets). Then ifdef on the preprocessor defines to select the server constant the compiler uses for each target.
Then make the product name and the bundle ID different in the two different target settings (so that neither the device or the Simulator will confuse the two app bundles).
With the current version of Xcode, you'd achieve this by changing the app's Info.plist file to use a different bundle identifier (and possibly also change the Product Name of the app in the build settings).
The upcoming version of Xcode, from what I've read in the prerelease documentation, has a feature that may simplify what you want to do quite a bit. However, since prerelease software is covered under NDA, I can't give you any details.
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 currently have an app in the Appstore. I need to make changes to the app, but they are significant enough that we've decided it would be easier to create a new Xcode project from scratch rather than modify our existing project. I don't fully understand everything that goes into an iPhone application, just enough to support the code and make basic changes. But I assume that the binary I upload to the Appstore, to replace my existing code there, needs to be similar enough so Apples sees it as the "same" code. What things in the new project do I need to make sure are the same as the old project so Apple knows it's the "same" app?
I've compared the Info.plist file in both projects to make sure they're the same. I only needed to change the bundle identifier in the new project to match the old. Also, the Product Name has been modified to be the same. I don't know if these changes are necessary, but they are the sort of things that I think need to be the same. Are there others? If so, what are they?
The only thing that matters, as far as the app store is concerned, is the app id (Bundle identifier). You can rename the app, change the icon, upload an entirely different program, whatever. As long as the app id matches, the store considers it the same.
Other things I would check are the Build Settings if the defaults are not suitable or the Code is having issues compiling and the Build Phases and Build Rules for all your Targets.
Essentially if your Code compiles fine and you have no issues within the Application then the Bundle Identifier and the name (Basically the Info.plist) needs to be the same to replicate.
Edit: If you have migrated from an older Xcode version then you may have different Build Settings and Build Phases. I would just see if compilation is okay and the App works properly in functionality under all your Targets
I noticed that there are different requirements for each platform here. I was wondering if it's possible to build a single project but with multiple targets where each target is Mac OS X (something like a CD / install build), Apple Mac Store, and iOS device.
IfIi'm going about this the wrong way then I'd love to know! I mostly develop on the PC but with the state of the App Store I'd love to spread out as much as I can!
Keeping separate targets for the Mac app store and an independently-distributed Mac application is simple. You just need to ensure that your receipt validation code is conditionally included on the app store target and not in the other target; and your custom licensing scheme is included the other way round. Things get a bit more complicated if you target different operating systems in the two targets, but they're not insurmountable: you can test for the existence of classes or selectors at runtime to ensure you never call newer API on older systems.
By the way, it's also worth having separate Info.plist files for these targets. Partly because you don't need or want to include things like Sparkle properties in your app store target, but also because each target should have a unique bundle identifier. The app store does odd things when you have an app installed that it thinks came from the store but really didn't, and you don't want to risk your updater or Apple's trying to update the app deployed via the other mechanism. But that's not really about organising your Xcode project, it's a deployment issue.
For the most part, yes. All Mac/iOS apps can be written in Objective-C and the code is very similar. However, you must bear in mind that iOS devices have different screen sizes from the Mac and even from each other. That means that the input metaphor is different, and that the UI is different. While it is possible to do what you want, it's not advisable to just code once and compile thrice.
That said, I don't use Xcode 4 so I can't tell you about that. Of you are looking to do different builds for different devices, you will want to write your app logic and your input logic as separately as possible. Then, you create multiple targets, one for each build. You define compiler flags for each target. In your code you will use those flags to use the appropriate code for your build.
At least as of 3.2.5, this is absolutely not a problem. You won't necessarily be able to apply all of your build settings project-wide, but you can specify them on a per-target basis.
Just add the appropriate-type target (Cocoa Touch, Cocoa, etc.).
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.
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