I have an existing project, quite old, with its own support system: in-app purchases, links on web pages, etc.
I would like to overhaul the app significantly front and back end, so much so that basically none of the original code will remain. Maybe even write it in Swift instead of Objective-C, mostly because it's getting harder and harder to find Objective-C documentation.
Is it possible to set up the new app in Xcode so that for all intents and purposes, the app store just considers it to be a new version of the existing app? The in-app purchases work with it, the links to the app store still work, etc.
Yes, no problem. As long as the new app has the same bundle ID as the old app (CFBundleIdentifier in the Info.plist), it is the same app in the eyes of the App Store and Apple. You can change everything else about it and they won't care: icons, user-facing name (CFBundleDisplayName), underlying language, interface, major functionality even. The in-app purchases are attached to that bundle ID so they just keep on working; the links to the app store won't change. You can start a completely new project, from scratch, and as long as the bundle ID is the old bundle ID, it's the same app.
Related
I've been developing a Swift app for a while now on my own individual developer account linked to my longstanding everyday AppleId - so the AppleId also has all my bought music, apps, appleTV and other content etc etc. As I have developed the app I have realised that it has considerable commercial potential, and so would rather release it under an organization (a private limited company) than under my own individual name.
The app itself is relatively straightforward, it is self-contained other than having a single non-consumable in app purchase. I have not yet uploaded the app to AppStoreConnect, although I have set up the app name and the in app purchase on AppStoreConnect for testing purposes. I would like to release in the quickest way possible now. Using XCode 14.
What is the quickest, most straightforward and trouble-free way to achieve my goal? Should I:
Release it under my own individual developer account and then ask apple to change my individual account to an organization account? Are there any complications with this given that this dev account is attached to my personal AppleId? How long does it usually take Apple to achieve the change? Does the App remain on sale throughout? Are there ever any problems or is there anything else I should be aware of?
OR
Set up a totally fresh AppleId and create a new developer account for the organization on this id? (I appreciate this will cost extra money but am willing to bear the cost). If I do this, how do I transfer the app from my individual account to the organization account? Do I have to go through the Apple 'transfer an app' process? Are there any pitfalls with this? When the transfer is complete, how do I alter my XCode set up to continue working on the app under the new account? Also, as I have not yet submitted the app to AppStore (although I have set up the name / IAP ) can I simply use XCode to point the app at the new account and upload it to that instead without invoking the Apple 'transfer an app' process - how would I alter my set up on XCode to achieve this?
I am currently in the process of setting up the company, and should have necessary info eg DUNS no etc fairly shortly.
While I'm familiar with development itself and I've already released one paid app on the AppStore under my own individual account attached to my everyday AppleId, this seemed to be a relatively simple and automated procedure. My main difficulties with my current problem seem to stem from the fact that I have never worked as part of a swift development team, and I understand very little around the actual 'architecture' of app development, eg XCode signing / teams / bundle ids etc, and I'm really struggling to understand the technicalities of the connection between XCode / Developer Account / AppStore Connect / AppleID.
I've looked through other posts on this topic but most seem several years out of date, and I am aware that AppStore functionality in this area has changed over the years.
Any help would be greatly appreciated - particularly if you can recommend which route to go down and answer any of my specific points. I have tried asking Apple, but all I get back are standard replies directing me to their app transfer process - unfortunately though I'm something of a solo outfit and I really need the benefit of people's experience here, as I need this process to go quickly and smoothly!
Cheers!
I've experienced a few apps that have had some time on the Mac App Store, but were later removed either by Apple or the developer for whatever reason. The developer then followed up with an offer where you could register the app by downloading one from their site onto your system with the App Store version already installed, which would unlock the full features of the new download.
How does one go about verifying an authentic purchase like that? Ideally I'd prefer examples in Swift if you would be so kind, but ObjC is manageable as well.
Here are official docs about receipt validation:
https://developer.apple.com/library/archive/releasenotes/General/ValidateAppStoreReceipt/Introduction.html
There’s also WWDC 2013 video 308 called “Using Receipts to Protect Your Digital Sales”.
It’s recommended to implement your own validation code, but it’s overwhelming and error prone if you’re new to this. There are projects on GitHub that can get you started.
Edit: My question may not have been clear: so I'll rephrase:
I'm asking: is there a way to update my app through the App Store (continue to push updates to users) if I decide to stop selling my app?
Original question:
I'm a mac dev assessing whether I want to sell my app through the App Store.
One question I had was, if I ever decide to stop selling through the store, will I still be able to issue app software updates to the initial users who downloaded the app.
Hopefully this is an easy YES. This seems important to me because if the answer is NO, then Apple's kind of locking the dev in to keep selling the app.
Define "stop selling the app". Meaning you are offering it for free, or pulling it from sale in the App Store?
If you are offering it as FREE, then YES, you can still issue updates to new and existing users.
If you pull the app from the App Store by "Remove from Sale", then NO, your app will not appear in the App Store, and the same goes for updates, you will not be able to push any new updates until it becomes available in the store again.
Apple does not want you to offer your app outside of the App Store. Back in the day you could provide it as an unsigned developer binary and Mac OS would complain, but allow you to install. Apple is now making it harder if not soon impossible to do this.
I already have a free version of my app in App Store. Now I want to add a completely new paid version of the same app (with extra features).
Is it required to implement In-App-Purchase or can I simply add the paid version as a new app?
You can create a paid version of your app with no problem. It will get approved. So it's really up to you. But using in-app purchase makes it more convenient to the user. They will be able to switch to full version of the app without losing any data (like achievements for a game, or documents created with the free app).
If you look at the app store, you'll see both options. There are many free "lite" versions of an app, and the full versions which you need to pay for.
In-App purchases are also common, yet they need more effort to develop.
I recently uploaded my first iPhone app to the App Store, and i'm thinking of creating a new app. I am wondering what new things I will need to create for it to be submitted. Examples: Bundle ID's, Certificates, or Provisioning Profiles, etc. Thanks!
You'll need everything you needed for the first app, except that your distribution certificate is a personal identity and lives in your keychain and at the Portal, so you only need one of those (until it expires, when you'll need to make a new one).
It might help if I make you a little chart here.
YOU: There is only one of you, so you only need one development certificate and one distribution certificate.
APP: Each app has its own bundle id and you'll need to tell that Portal what that is if you want to submit it to the store or hand it out in an ad hoc distribution.
PROFILE: A profile unites YOU and one APP. Thus it is unique to that APP and you'll need a new one for every APP you want to distribute. -- EXCEPTION: For convenience, Apple now allows you to develop many kinds of app on a device using a single team development profile where the APP is effectively a wild card. This was not always the case though; it used to be that you needed a new development profile for every app too, just as you need a new distribution profile for every app. And for apps with special needs you may still need a development profile just for that app.