if we want to release the application which is ios16 ready then what approach should be followed? What should be updated in metadata? There are a few things that you must never mention in the app metadata. In particular, things like this will be rejected by Apple: Includes a workaround for a bug in iOS. Supports a new iOS version that's still in beta. Can now share data with our Android app. Some previously paid features are now free. The solution is simple, just don't mention those things. Write a vague "what's new" message like "Miscellaneous bug fixes".

found out the there is a new 2013 agreement That has not been ratified by the US Congress, so the 1974 treaty still applies. Non-US residents and non-US legal entities are not required to provide a US tax ID. Interesting.

The transformation matrix is singular when the scale factor is zero, as it will be at the end of your animation. You may be able to ignore it, or maybe don’t scale all the way to zero.

Yes, there are awkward issues with links, but (a) there is no solution that does what you hope for in every case, and (b) making any change will break some existing code. In code like your first sample, you cannot assume anything about what getwd() returns. In paranoid code, e.g. anything with security implications, you should be even more cautious because you should assume that someone else has moved a link while you weren't looking.

The “private client” should hold the licence, shouldn’t they?

I believe that’s not possible. (There is a similar situation with an iPhone and wifi-only iPad.) What you can do is send location data from the iPhone using Bluetooth LE using an app such as “LE GPS”. (Note LE, not classic Bluetooth.) But the Mac (or wifi-onlt iPad) doesn’t understand that natively, so each map app on the Mac needs to add support for receiving it. I did that for one of my apps, but I believe approximately zero people have ever used the feature.

You can certainly use C++, in XCode, for macOS (or iOS) development. My current project is 85% C++, 15% objC++. Before Swift, it was really very easy to combine C++ with objective-C in the same file - they refer to that as "objective C++". But that's not possible with Swift. You can combine Swift with C++ in the same project, in different source files, but I think you need to use only C semantics where they communicate. The best approach will depend on the nature of the app you want to make. To port from Windows, you'll probably be able to keep the non-UI code unchanged in C++, but you'll need to completely re-write the UI. If you have the patience, it may be best to start by ignoring the C++ aspect and learn how to build a GUI using SwiftUI. Do a few tutorials, until you understand what is possible and are getting familiar with the terminology etc. Then, think about how you might divide a project between the different languages. At this point I don't think I'd recommend using much objC. Apple are introducing a few "Swift-only" APIs now. It could be more convenient than Swift in a few cases but they will be rare and it's another thing to learn. Good luck!

where do I find these files? According to "man xip": --expand <input-file> Expands the archive into the current working directory.

It should never reset to zero.

No

People leave critical reviews for my apps and I don't know about them so the app rating goes down. Knowing about the bad reviews will not stop the rating from going down. Knowing about the bad reviews, and then replying to them, will also not stop the rating from going down. My advice regarding App Store reviews is still “don’t look at your reviews”. Nothing good can result from reading them, and it can be very bad for your mental health. This advice predates the reply feature. I did reconsider when that feature was added, but on reflection I think “don’t read the reviews” is still the right choice. I guess that if you have read a bad review it could be cathartic to reply saying “Idi0t user”, but that doesn’t stop the rating from going down, and it’s still less healthy for you than not reading in the first place. I suppose you might imagine that someone posts a review saying “app doesn’t have feature X, 1 star”, and you can reply saying “it does have feature X, press the button that says X”, and then they will read that reply, understand their mistake, and change the rating to 5 stars. Realistically, though, that’s going to happen about 0.0000% of the time. Most likely, after posting the initial review they will have deleted the app, and their idiotic review will remain there unchanged.

Switching from for in to a while < loop drastically reduces the execution time. The other thing you're doing there is changing from .append to [idx]. Do you have optimisation enabled? Any other build settings to fiddle with?

Try changing the C code to use arc4random() instead of rand(), and see what the slowdown is. If C-using-arc4random() is similar to the speed of the swift code, then I think we can say that the speed difference is because Swift's float.random is using the arc4random algorithm, or similar. But if the C code is still faster, there must be other issues involved. As for how to fix your problem - you can, of course, call the C rand() function from Swift using suitable bridging. Do be aware of the well-known limitations of rand() if you choose to do this. If I were trying to generate lots of pseudo-random numbers very fast, I'd search for SIMD (NEON) code to do it.

Correct, you're not missing anything.

Keychain doesn't work properly when you're connected using ssh. I believe that unlocking the keychain requires the plain text of your macOS login password, so it can't possibly work over ssh. It's not obvious why xcodebuild would need access to the keychain, but there are a billion other non-obvious things involved here. Try running this immediately before invoking xcodebuild: security unlock-keychain