No.

that requires active cooperation on behalf of the user What happens if someone steals the phone? I'm curious as to whether the phone would need to be cracked in advance in order to dump the RAM in this way, or whether it can be done afterwards. You need to think carefully about your threat model I think the main threat model is probably "we have this list of security best practices and I'll get fired if we don't comply with them".

MoltenVK is interesting. I've looked at it but never tried to deploy it. A few years ago, we could write code using C++ and OpenGL ES and it would run on iOS, Android, on the web (using Emscripten and WebGL), and even on desktop Linux and likely Windows. I have a largish demo that does most of that. But since then there has been some unhappy divergence: iOS has deprecated OpenGL ES and invented Metal, and the replacement of ObjC with Swift has made C++ more difficult to use; Android now has Vulkan. So it is tempting to look for tools like MoltenVK that might help to re-unify the platforms. Right now, my feeling is that the more promising technology medium-term is webgpu.h. WebGPU is a replacement for WebGL that is more "modern" like Metal and Vulkan (but is different from both), and webgpu.h is a native API for it. So you can use it, with C++, on the web (where webgpu.h is a thin wrapper over JS WebGPU), and on native platforms with a library that translates webgpu.h calls to Metal or Vulkan (e.g. Dawn). This doesn't seem to be ready to use quite yet but it's coming soon enough that it's worth considering if you're about to start on a new project. I would be interested to know if anyone here has any experience with any of these things.

There is no "No GPS signal" notification from Core Location. All that you can do is determine that you have not received a location for some period of time, and assume that the signal is lost. Having said that, what most apps do is simply continue wait, i.e. don't try to present any sort of message to the user.

is it OK to export [Apple's symbols and/or fonts] for use in ... an alternate version of my app for some hypothentical non-iOS platform? NO.

Yes, you can still create and submit apps written in ObjC. For how much longer this will be true is unknown. My guess is that updates to existing apps will continue to be accepted for a good long time. It's possible that new apps may be refused sooner. Of more concern, some new iOS features may have Swift-only APIs. And of course there may be ObjC-only bugs that don't get fixed. Why do you want to do this?

many MKPolylines and MKPolygons By "many", do you mean thousands or millions? Are they all visible, or are many of them off-screen? How does the number of lines or points compare with the 50000 number in the error message?

WARNING Posts are being removed from this thread.

I recommend that you watch WWDC 2022 Session 102 Platforms State of the Union, and specifically Josh’s section starting at 3:43. From the transcript (with my emphasis): Josh Shaffer: A great developer platform provides tight integration between programming language, frameworks and tools. When all three fully complement one another, we can ensure that common things are easy, and even uncommon things are possible. Now, getting that right shortens the path to building a great app, and it benefits everyone. Customers get a consistent experience, like scrolling that always feels perfect. And you're able to focus your time and effort on what makes your app unique. But designs evolve, hardware advances, and what was once cutting edge becomes the expected baseline. The Objective-C language, AppKit & UIKit frameworks, and Interface Builder have empowered generations of developers. These technologies were built for each other, and will continue to serve us well for a long time to come, but over time new abstractions become necessary. For a while now, you've seen us hard at work defining the next generation of integrated language, frameworks, and tools: Swift, SwiftUI, and Xcode Previews. Tight integration in a development platform like this requires that all three pieces be designed and evolved together, both driving and driven by one another. Swift result builders were inspired by SwiftUI's compositional structure. SwiftUI's declarative views were enabled by Swift value types. And Xcode Previews was specifically designed for, and enabled by, both. Now, the result is the best development platform that we have ever built. And this year, Swift, SwiftUI, and Xcode all have fantastic updates that take this vision further, and make it even easier for you to build great apps for all of our platforms. And it all starts with Swift. Now Ben from the Swift team is gonna tell you all about what's next. Is the "long time to come" quote what you're referring to?

I've also had posts that I thought were innocuous removed by Apple. No this is not a spam filter. And unlike other forums, here they just vanish rather than leaving a "this post has been removed by a moderator" message. Edited to remove "though not recently", as I see that one of my replies in the same thread has also just been removed!

Dear "App Store Connect Engineer", in the thread Scott has linked to, I posted a message referring to an episode in the past which maybe Apple finds embarrassing and want the world to forget about. Or, maybe whoever deleted my post thought it couldn't possibly be true because it has been erased from Apple's internal corporate memory. Presumably you will now delete this post too! Feel free, I don't care.

you need to listen to what Josh said as a whole. I tried to listen but I was getting 1 FPS video with no sound. So I looked at the transcript. Can you at least confirm whether I have quoted the right part of the transcript?

Also what's the problem with hard coding sensitive information into source code if it will be encrypted? If I understand correctly, the hackers are able to attach a debugger to your running app and observe the decrypted instructions/data.

If I understand correctly, you are calling SKReceiptRefreshRequest on startup if there is no receipt present - correct? Why do you do that? If you have IAPs, and you want to be sure that previously-purchased IAPs are correctly enabled in the app, then you just need a prominent "restore purchases" button that calls ReceiptRefresh when pressed. The app should wait for the user to press the button. If your concern is to prevent pirated copies of your app from running on hacked devices where a (valid) receipt is not present - sorry, you can't do that in this way.

I think you can’t. Here is an old thread: https://developer.apple.com/forums/thread/48088