I have an app on the App Store and I downloaded it onto my phone. Now, I want to integrate iCloud and Push Notification into this app. If I open Xcode and run it on the same device, it overwrites the App Store app. My goal is to have 2 versions of this 1 app on my phone: 1 from the App Store and 1 from Xcode for development purposes.
I have read two articles and can't come up with a solution:
Unable to install same apps on 1 device
Create Multiple Targets/Apps for 1 Xcode Project
By changing the Bundle Identifier, it is possible based on the article above. But will there be a problem when testing iCloud and push notifications? The App ID and what is in iTunes Connect relies on the Bindle Identifier and when testing iCloud and push notifications, I need iTunes Connect. So this is the problem from what I see.
Any suggestions?
Create a new bundle ID (say with an added .CLONE suffix). Use Xcode to build your App Store submitted code (from your source repository) identical except built using this new bundle ID. Install it side-by-side with the original App Store app (identical source code).
Then manually copy your notes out of your App Store app and paste them into the new Clone app. You can use Xcode to back up the new clone app's sandbox. (There might also be tools that are able to pull you app's notes DB out of an unencrypted iTunes backup, if you make or have such.)
Then delete your App Store app (if needed) and install any new version as needed for development and testing using the original bundle ID for iCloud testing.
Your real non-test data will reside in the Clone of your earlier App Store app during development. You can copy it back into the App Store submission when done.
Related
My app project has an odd name and I would like to use a more readable name for App Store submission (Display Name in Xcode 14 has been changed to more readable name). What I did was to change name in App Store connect and now there are 2 listings for my app with the same bundle ID in App Store connect . However when I was distributing it in Xcode 14, the app name selected is still the old one (less readable one) on submit page and is not the more readable one. What is the right way to choose a different app name in App Store connect for App Store posting? The app hasn't be pushed to App Store yet.
The app name can be changed in App Store connect. The uploaded build will be displayed (under TestFlight) under the listing of App Store connect by matching app's bundle ID. Author can choose which build to publish in App Store connect. The build can be uploaded in Xcode.
I have two apps on Appstore Connect with different app identifiers. One is in the app store while the other is on TestFlight. Is it possible to replace the live app with the one on TestFlight?
Locally these apps are built off the same bundle ID and the app identifier is changed when pushed through Fastlane. They share a signing certificate as well. If I want to replace the live app, do I just need to change the app id for my new app to match the live app?
Yes you need to change the app id and then compile the application that you would like to submit.
Off-course it will replace the old binary of the application. So the code and the UI would be updated accordingly.
When I install my app through Xcode, App Store no longer recognizes that the app is installed. This makes things like deep links difficult to test.
I have verified that my Product Bundle Identifier is the same for Debug and Release (it's different for AdHoc, but that shouldn't matter in this case). When downloading from App Store, it does not add a second app, it simply updates the previous app.
I had built an app which is already available in the app store with version 1.0. This app has local database (i.e. SQLite). Now I am working on next Version (i.e 1.1) and in this Version I have added a new table to my local DB. With this the development is complete.
Now, using testFlight I am performing Internal Testing.
Let's consider two Scenarios:
Case 1:
On my device, I had freshly installed the beta build version 1.1 from testFlight. Once installed, I checked my local DB and found that my local DB is updated with the newly added table.
So this is working fine.
Case 2:
Let's consider a scenario Wherein on my device I am running my app store build i.e version 1.0 and now I am installing the beta build from Testflight. Once clicked on install button I get a message "Do you want to update the existing app" and by clicking on the ok button the beta build which is version 1.1 is installed on the app.
But when I checked my local DB I found that the database is not updated with the new table. i.e. It's still showing the older database into the app.
Why only my local database is not updated in the second scenario?
Does testFlight build do not override complete app store build along with local DB?
If you want to really test migration process on production you have to install your app with Itunes because TestFlight or the build process via xCode does not completely override the App.
Install an ad hoc distribution of an archived build of the update using iTunes on a device that already has the old version of the app installed.
Test your App with Itunes
I had similar issue with CoreData. I had to make a migration of my DB, and I was unable to test the real scenario of updating the App.
The only true test was :
Have the old app (from the actual store) installed on the phone.
Install your new App with Itunes with an Ad-hoc distribution.
We are going to submit a prerelease version of an app to external users, but I wonder: what will their experience be?
The user had a production App Store version of the app on the device, and now installs a new beta via TestFlight. Will this be in-place update, with the data preserved, or a completely new install with data wiped, or will TestFlight's version be installed next to production - so that the user has the app twice?
Testing is over, and the production-ready version is submitted to the App Store. Will the tester be able to update to the new App Store version seamlessly (in-place), with the beta version's data preserved? Or is it a complete wipe? Or will beta stay on his device and he has to download a new full version from scratch?
By the way, I have submitted another question regarding version numbering beta vs. production.
According to https://developer.apple.com/testflight/
Once you accept your invitation, you’ll be able to download a
beta version of the app you’ve been invited to test. If you already
have the live app installed on your device, the beta version of the
app will replace the live version. When you’ve downloaded the beta
app, you’ll see an orange dot next to its name that identifies it as a
beta. TestFlight will notify you each time a new build is available
and provide instructions on where to focus. You can easily offer
feedback by tapping the Provide Feedback button in the App Details
view in TestFlight. An email automatically opens with pertinent app
and device details, and you can add additional details and
screenshots.
It's said that the beta version of the app will replace the live version. The reason is the beta app has exactly the same bundle identifier with the one on the App Store.
After installing the beta app, the user will still see the updates from the App Store as the live version has been installed (without losing any data) because the beta app is deployed using exactly the same certificate.
I think the things changed a while ago.
Even if you have a beta (which is signed with production certificate - remember, no AdHoc needed), the TestFlight version will function as an update for the existing app. I tested those things and can confirm no NSUser defined entities were overwritten or deleted by the TestFlight build.
For the second part: the user can preserve saved data if the application is not a major build (I mean, you cannot expect a database stored in some format to work with another new model of your app version). To be sure your app does not clear or attempt to modify previous content, put a version check on the new one. If there are data found, update to the new schema. I think this is the way to go. Anyway, you cannot have duplicated versions of the app because they are signed by the same profile.