If you want a syncing solution you can use core data+CloudKit. This will allow your users to use the data offline. The sharing intergration using core data with CloudKit isn’t quite there - it exists but I don’t think anyone has been able to get it to work. But you can share directly with the CloudKit apis and write your own integration with Core data. This is how most people do it. you can also store your data on an external server and access it directly. This will need an internet connection unless u write your own syncing.

Start by doing a search on google for swift tutorials and start with an introductory tutorial. If you aren't much of a self learner then enrolling in a programming, IT or computer science course at your local educational institution is another starting point. it sounds like you don't have any background in programming, so yes it will take a significant investment of time. 6-12 months at least if you are serious about it, maybe more.

Seems to be a bug in the iOS16 SDK for DatePicker. you can safely ignore it. I can't remember what it was but there is a compiler flag u can set so it reduces the error message down to one line to clean up your console. you can probably find it with a google/stackoverflow/forum search

to fix this I had to reset the environment, let the record tables be recreated and then re-add the recordName and modifiedTimestamp indexes for the public database. exporting the environment schema and then reimporting didn't work.

id also like to know this.

still broken in iOS16 final

that's an old beta, try getting the latest one

start by telling us what the app is, what u are doing to make it crash, what os and device you are using, any error messages, your code. no one can help you with "can someone help me understand why this app is crashing? thank you so much!"

try this let fetchRequest : NSFetchRequest<Item> = Item.fetchRequest()     fetchRequest.sortDescriptors = [NSSortDescriptor(keyPath: \Item.itemNo?, ascending: false)]     let results = try context.fetch(fetchRequest)

its your device, do what u want

yea I put it as high in the hierarchy as I can. for me that's generally on the content() view - makes it easy to know where it is, particularly if u want to call it from multiple different places var body: some View { content() .fileImporter {} .fileExporter {} } func content() -> some View { //all the other views }

Sorry not helpful but - "Wheres the any key!" ;-)

No, but from memory (I did it over 10 years ago) you will need to create a US tax file number or whatever they call it there. the iTunes connect process will take you through the process (or at least it used to). I think you also need one for Japan and one other country (Canada?) from memory if u want to avoid withholding taxes for sales in those locations. not sure if the process has changed now. feel free to correct me if it has.

seems to be fixed in ios16 beta 4

what I do is write the apps in swiftui then its pretty easy to bridge to UIKit for a particular view or part of it to get all of the functionality u have listed. I believe there is a WWDC session on this specifically. SwiftUI and UIKit generally plays together pretty well. Tbh its way easier and faster to do it that way than write everything in UIKit. some of what you have listed have been implemented in native swiftui already. eg pull down to refresh - have a look at the "what's new in swiftui" from the past few years wwdc's. I believe its called .refreshable MapKit has been recently brought into swiftui. not sure about the specific functionality you need but I recently converted my UIKit maps components into the native swiftui version. For the custom controls on a Video view, I overlayed some custom swiftui controls over the top of a bridged AVKit video player using a ZStack. it'll be another decade before everything is in swiftui, if ever. they still haven't got everything in objective c implemented for swift (try catching a core data fetch thrown exception in swift) and there are still a few obscure functionality that u still need to fall back to C for. So it'll pay to learn how to bridge the UIKit controls into swiftui so u can move to swiftui more seamlessly.