can the app be rejected only for some countries and approved for others when submitting a new release? No. if the app violates some country's law or guideline, will the app be unable to release globally until we have resolved all the issues? I don't know about this. My guess is that it would initially be rejected globally, but you would then be allowed to remove it from the affected countries and have it approved. What sort of issues are you concerned about?

I successfully submitted a new app without 6.7" screenshots about a week ago.

I have a 16 GB M1 mac mini and an 8 GB M2 MacBook Air, and their performance is essentially the same, as far as I can tell. It may depend on the sort of app you are creating. I think the most demanding thing that I've done recently is preparing preview videos.

I see I can Remove an App from the App Store under General > Pricing and Availability. Will I still be able to push updates if I do this? No. I think the best way to discourage new sales is to put “don’t buy this app” in the promotional text etc. and increase the price to $lots.

iTMSTransporter support for IAPs was removed late last year, IIRC. We are now supposed to use the App Store Connect API. Cos XML is so like 1990s, right, and JSON is the new thing we should all be using.

Presumably something like your contract with "the government" ?

Can I use personal account to distribute the app for beta internal testing but finally get it reviewed and publish using business account? Probably. The only issues I can see are with the bundle ID and app name; when you come to create the App Store record for the business version of the app, it will need to have a different bundle ID, and possibly a different name. Changing the bundle ID is not a problem, it just means that the beta testers will need to delete the old version rather than having it automatically replaced by the App Store version. Not a problem if the testers are a handful of people within the business, but maybe a problem if it's a wide public beta. The rules about name collisions have changed over the years; I think you will be OK if the test version has never been released on the App Store, but to be safe you might want to use a different temporary name.

1 - am I missing something here, or is Apple really not allowing my app updates to support 32-bit devices? I thought this became impossible a long time ago. 2 - if I do release a 64-bit only build to the store, will people on 32-bit devices be able to download an older version of my app (if they don't already have it installed)? Does the App Store app function at all on an iPad 2? If it does, they may be able to install the most recent supported version if they have previously purchased it, but not make new purchases. It may be that, for example, they can purchase the app on a new iPhone and then install it on the old device. I suggest that you try installing some other well-known apps on an iPad 2 and see what happens. I have some old devices and the main thing that has stopped them being useful is expired root TLS certificates.

AAaaarrgghh I wrote a long reply but this fucking useless shitty forum said "Unauthorized" when I pressed Submit and then Back shows an empty box. Fuck fuck fuck. Summary: Many cameras don't even have a time zone setting, and the ones that do, the user probably is not remembering to set it. The iPhone does know the time zone. Looking at the EXIF metadata for a photo from an iPhone, it does include the timezone. But getting arbitrary EXIF fields using PHAsset is awkward. You have to fetch the entire image data, which is not great if they are e.g. iCLoud images and you just want to show thumbnails on a timeline.

It does not work in production, and has caused Review to reject my app. Doesn’t work in production, or just doesn’t work in app review? I'm at a bit of a loss as to where to go from here. Submit an update that includes the check but continues anyway if it fails. This will pass app review. Send yourself some diagnostic data to tell you whether it is passing or failing for end users. Or even just something that you can test yourself with an app-store-purchased copy of the app.

Default is fine, I guess.

With the non-SwiftUI photo picker, you would persist the PHAsset's "local identifier", which is a string. PhotoPickersItem seem to be a new SwiftUI thing, and I don't immediately see anything equivalent to the localIdentifier.

Do you have pausesLocationUpdatesAutomatically set? If you don’t know - you do have it set; the default is enabled, to the surprise of everyone who discovers it.

I don't know for sure whether Apple allows this; I suspect not. But you have more to worry about - specifically, money laundering regulations. Anything that allows people to transfer funds from one bank account to another in a different country needs to be supervised to prevent it being used to disguise the proceeds of crime.

What is the minimum copyright information needed? Nothing. You own the copyright in your code by default.