That makes sense. I think it's not going to be too bad for customers. The data in the containers is basically transient cache and temp files (another reason why this particular App Store restriction is probably inappropriate in this case). The user's programs are stored in NSDocument bundles wherever they put them on disk (these bundles are used by the IDE via security scoped URLs which we bookmark and pass to the XPC service in the new versions of the app). In all app versions, a customer can wipe the app container, even the group container, and as soon as they restart the IDE it's all recreated and works perfectly. I test this use case regularly and it's bullet proof. Financially, the app uses (very cheap) monthly auto renewing expenses. The app itself is free to download (the auto renewing subscription is required for building programs, and comes with a month free trial) and doesn't have any permanent in-app purchases that people would lose. I can work with the new developer (a good friend), customers, etc. to make sure that no one would lose out on anything. Logging a bug makes sense!

Thanks. Oof. That is not good to hear. So presumably the only way out of this is if I hand the source code to my friend, they build effectively a "new app" with a new app id, new name on the store, new description, etc. They can "take over" from me with the new app, I can put something to that effect in my app description perhaps and remove my app from sale. Then existing customers who have downloaded it will still be able to use my version but all new people looking will go to his instead. Sounds like that's just about the only viable approach?