I can tell you how I got into iOS development and try to answer some of your questions. I started by trying to find tutorials online, but the ones I found were either too simple or did not explain anything properly. I even bought a course at Udemy but that course also did not go into the details as much as I had hoped. I finally stumbled upon the iOS course at Stanford: https://cs193p.stanford.edu Back then it was available at iTunes U (which does not exist anymore), and included the lecture videos and the course work. I watched all the videos and, crucially, did all the course work. Doing the exercises was really essential because when you listen to the lectures it all sounds easy but when you try to do it yourself it's not so easy 😄 That course was exactly what I needed: it did not require any prior knowledge except for general programming, went into the details but explained everything. Definitely can recommend it if the videos are still made available, you will have to check. To your questions: Should I start with UIKit or SwiftUI? - That's not so easy to answer. I would say in the end you probably need both. Since in my opinion SwiftUI is more modern and cleaner, personally I would start with that. But if you want to focus on only one, you might want to start with UIKit, since it is still more capable and a lot of existing code is still based on UIKit. How important is it to learn Objective-C - Not at all important, you can safely skip that. You will probably never write new code in Objective C. What skills/topics should I master before moving to more advanced concepts? - That's really up to you. I would probably start with learning Swift and how to create UIs, since pretty much any app needs that. After that, learn whatever interests you. What types of projects would you recommend for someone at my level? - I think the typical first app is a To Do app. It presents elements in a list, and you need to store the todos somewhere and be able to update them. And in SwiftUI, that is actually surprisingly simple, including persistence. Which iOS-specific design patterns (MVC, MVVM, etc.) should I learn first? - That was actually one of the hardest topics for me. Even the Standford course did not go into architecture. The main problem is, architecture only becomes important in bigger code bases, and even more so when you work on an app in a team. But as a beginner, you typically work alone on small apps. Having said that, UIKit is based on MVC (or Apples interpretation of MVC), which can have a lot of problems. That's why there are so many alternatives. If that topic interests you, read up on it and try it out yourself. As for SwiftUI architecture, you might want to look at the IceCubesApp: https://github.com/Dimillian/IceCubesApp It is an open source Mastodon client, written completely in SwiftUI and explicitly meant as a best-practice example for a large SwiftUI app.

Silent push notifications are not guaranteed to be delivered, and even for notifications visible to the user, background execution of the app is not guaranteed. The system decides, based on many factors, whether to execute the app in the background because it received a push notifications with "content-available": 1. In fact, terminating the app may be interpreted by the system as the user not wanting the app to be executed and might halt background execution altogether. Therefore you should not rely on push notifications as the only way to deliver data to your app. You should instead implement a mechanism for the app to download new data whenever it seems useful (e.g. when the app starts, when the app enters the foreground etc.). Push notifications may then trigger the same mechanism for downloading new data, but nothing is lost if they don't.

All I can add is that from our experience, even when push notifications are visible (i.e. contain a title and body), background execution of the app is not guaranteed. It is solely decided by the system whether it triggers background execution of an app. I am not aware of any mechanism to force background execution. I assume one must exist, though, because to my knowledge mobile device management also relies on silent push notifications to update a devices' settings. One question about your use case though: you say that the app updates its schedule in the background to deliver local notifications. Could the notifications not also be sent by the server? Then you would not need to rely on background execution at all.

As far as I know, removing an app from the App Store does not prevent users who have already installed the app from using it. It only prevents further downloads from the App Store, i.e. new installs or updates. Also, it is against the App Store rules (again, as far as I know) to just publish an update that e.g. only shows a message that the app is not functioning anymore (since apps on the App Store need to be functional). Since you mention a backend: could you just shut that off? Does your app handle that in any way and show a message?

Bug report submitted under FB19401153.

Did you specify a sound file in the JSON payload as explained in the documentation Create the JSON payload?

Interesting. We use UIApplication.shared.setAlternateIconName() in the same way as you describe: the async/await version in a @MainActor annotated method. And we have no problem, neither in Xcode 16.3 nor 16.4. Both simulator and physical device.

All I can say is that Drag & Drop works for me. Depending on the file type, it opens the Photos or Files app, respectively. It does sound like there is something wrong with your installation.

Still crashes for us.

This seems to be related to this problem for iOS Simulators: Xcode 16.4 iOS 18.5 simulator crashes for Apps requiring webkit The crash only occurs when some specific methods are called on WKWebView and some other types. One workaround for iOS simulator was providing a path for libswiftWebKit.dylib via DYLD_FALLBACK_LIBRARY_PATH. I don't know how this would be done in Previews though.

As I understand the documentation, this is indeed the expected behavior: By using the completion handler, the task bypasses calls to delegate methods for response and data delivery, and instead provides any resulting NSData, URLResponse, and NSError objects inside the completion handler. See dataTask(with:completionHandler:)

Thank you for posting this here! Our app is affected as well and I have been trying to produce a minimal example in a new project all afternoon but failed, just like you said. To add some information: I can crash our app by simply accessing URLSession.shared or URLSessionConfiguration.default (but not by simply accessing URLSessionConfiguration.ephemeral) in the initializer of our AppDelegate.

For me the option 2 is not working (and option 1 is not really an option as we need to support older iOS versions). I followed the instructions, added the DYLD_FALLBACK_LIBRARY_PATH argument to the Run configuration of my scheme like this: DYLD_FALLBACK_LIBRARY_PATH=/Library/Developer/CoreSimulator/Volumes/iOS_22F77/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.5.simruntime/Contents/Resources/RuntimeRoot/System/Cryptexes/OS/usr/lib/swift But the app still crashed, and when it logs the dyld config, it prints this: DYLD_FALLBACK_LIBRARY_PATH=/Library/Developer/CoreSimulator/Volumes/iOS_22F77/Library/Developer/CoreSimulator/Profiles/Runtimes/ So it seems my value for DYLD_FALLBACK_LIBRARY_PATH is just ignored. I checked it a thousand times and don't understand what I'm doing wrong. Is this working for other people too? Edit Found the solution, see comments if you run into the same problem.

One way would be to perform the import in the background in a @ModelActor. Something like this: @ModelActor actor ImportService { func import(data: [Data]) throws { for date in data { let model = Model(/* ... */) modelContext.insert(model) } try modelContext.save() } } This way the import will not block the UI, and the imported data will only be visible in the UI after modelContext.save() is called. I haven't used SwiftData in a real-world app yet, however, so do be careful. For example I don't know if SwiftData will keep the models in memory until save() is called, so you might have to save more frequently. But even then, the UI will not update for every newly inserted model but only when you choose.

Thank you for the quick answers! To be on the safe side I had a co-worker test this on his iPhone, and there it worked. So I rebooted mine and tried again, and now it works on mine as well. So false alarm I guess.