User Profile

I installed Xcode 15 without downloading iOS 17 simulator. When I opened my iOS app project in it, Xcode showed "iOS 17.0 not installed". This is as expected. My question, however, is that after I connected my phone, it's shown in "Manage run destination", but not in Xcode deployment target selection list. Does anyone know if this is as expected? Do I have to install iOS 17 simulator to get my device shown in Xcode? Thanks.

After I downloaded Xcode 15, I use the following approach to download and install iOS 17 simulator: Download iOS 17.0 simulator runtime from Apple website Then run xcrun command to install it: $ xcrun simctl runtime add iOS_17_Simulator_Runtime.dmg (BTW, I can't install iOS simulator from within Xcode directly because downloading the image always failed. I have a fast Internet connection. The issue seems to be intermittent connection failure.) The iOS simulator was installed successfully. However, I find the behavior of xcrun command is very confusing. Below is what I observed. First this is xcrun command output: $ xcrun simctl runtime add iOS_17_Simulator_Runtime.dmg D: EEF873B8-E0E6-4A0E-9A1E-C4C7E6D3BE1A iOS (17.0 - 21A328) (Ready) I suspect the output means it mounted the img somewhere. However, I can't find that disk in Finder. I checked the manually page and found the following: add <path> [-ma] Add a runtime disk image to the secure storage area. The image will be staged, verified, and mounted. When possible the image file will be cloned so no additional disk space will be used. If stdout is a terminal and a copy is required then progress will be reported. I wonder what's that "secure storage area"? Is that the reason why I can't see the disk? What's more confusing is that, shortly after the xcrun command completed, a GUI message box popped up, displaying a messsage "Verifying iOS 17.0.simruntime". This took a while. Then the message box disappeared and nothing more happended. At this time I opened Xcode and verified iOS similator was installed indeed. I monitored disk IO during the entire process. I observed a lot of read ops but few write ops, which is odd. I understand why there were many read ops, but I expected the same amount of write ops also. Is it due to COW, plus the fact that the image is mounted rather than uncompressed? The manual says "The image will be staged, verified, and mounted." I wonder what does "staged" mean in this case? Also, the mannual says the image is mounted. So my first thought was that I shouldn't move or delete the image file I downloaded. Then I noticed the manual also says "When possible the image file will be cloned so no additional disk space will be used." So I think it's OK to delete the image file? I'd like to confirm my understanding first so I haven't tried it yet. Thanks for any explanation.

(This is a show stopper issue for me to use VStack or LazyVStack in my app. I posted the issue here on SO but got no reply. So I'll ask in this forum.) What I'm trying to implement is a very basic behavior: I have some items in VStack and I'd like to scroll to some item when the VStack is shown. The issue is scrollTo() scrolls too much and leads to invalid UI. See diagram below. Setup: there are 3 items in the VStack and I'd like to scroll to the last one. +--------------+ +--------------+ | c | | a | | | | b | | | | c | | | | | | | | | | | | | | | | | | | | | +--------------+ +--------------+ (a) What I saw (b) What I expected The UI in diagram a is invalid and misleading because 1) it's impossible for user to get such UI interactively, and 2) when user see it he would think there is only one item. I have been investigating how to work around the issue but couldn't find one. I found two discussion that might be relevant, but both of them were about iOS 15. I don't find any discussion on a similar issue on iOS 16. Below is the code to reproduce the issue. I filed FB12173661 yesterday. I wonder if anyone has a workaround? Thanks. My environment: Xcode 14.2, iOS 16.3.1. I'm installing Xcode 14.3 and will verify it on iOS 16.4 soon. struct Item: Identifiable { var id: UUID = UUID() var value: String } struct TestView: View { var items: [Item] var scrollTo: UUID var body: some View { ScrollViewReader { proxy in ScrollView { LazyVStack { ForEach(items) { item in Text(item.value) } } .onAppear { DispatchQueue.main.asyncAfter(deadline: .now() + 0.1) { proxy.scrollTo(scrollTo, anchor: .top) } } } } } } struct ContentView: View { var items: [Item] = [Item(value: "a"), Item(value: "b"), Item(value: "c")] var body: some View { TestView(items: items, scrollTo: items.last!.id) .frame(maxWidth: .infinity) } }

I have recently released a new app, which is free to download and has a subscription to unlock a feature. When I go to "Promo Codes" page in App Store Connect, I find both "App Promo Codes" and "In-App Purchase Promo Codes" are list. I wonder what's the use of the former? This is a freemium app, so I think it's useless?

I'm testing my app's subscription code in Xcode and run into a weird issue: my phone always receives the purchase transaction, although I have deleted it in Xcode (Debug -> Storekit -> Manage Transactions shows nothing). It's on a real phone so I can't resort to the Erase all contents approach in Simulator. I restarted both my laptop and my phone, but the issue persisted. Uninstalling the app doesn't help either. Also, I'm pretty sure it's not my code issue because a) it used to work fine (the issue showed up out of nowhere few days ago), b) the same code worked fine on simulator, and c) I debugged the code and verified the code did received a transaction from somewhere. Did anyone observe this issue and how do you solve it? Any suggestions would be appreciated.

I'm adding subscription support to my app. The subscription unlocks a feature of the app. From what I read, Apple's Paid Applications Agreement, Schedule 2, Section 3.8(b) has this requirement (emphasis mine): Links to Your Privacy Policy and Terms of Use must be accessible within Your Licensed Application. My question is about Terms of Use (I'll refere it as EULA). I'm an individual developer and my app is currently using Apple's standard EULA, which is the default setting in App Store Connect. I wonder what kind of EULA I should link in my app's subscription disclosure to meet the above requirement? Can I just link to Apple's EULA, or should I create a EULA specific to my subscription? I have no problem in writing a EULA specific to my subscription, but my concern is that if I did it, would my app be licensed only by my custom EULA, or a combination of Apple's standard EULA and my customer EULA? I would hope the latter, but I'm not sure, because I find the following in Apple's standard EULA (emphasis mine): Your license to each App is subject to your prior acceptance of either this Licensed Application End User License Agreement (“Standard EULA”), or a custom end user license agreement between you and the Application Provider (“Custom EULA”), if one is provided. I checked a few apps by other developers and found they all created their own EULA. I haven't found any one linking to Apple's standard EULA. So I wonder what's the proper way to do it? Thanks for any help.

Hi, please see the example code below. The app has two views: a list view and a detail view. Clicking an item in the list view goes to the detail view. The detail view contains a "Delete It" button. Clicking on the button crashes the app. Below is my analysis of the root cause of the crash: When the "Delete It" button gets clicked, it removes the item from data model. Since the detail view accesses data model through @EnvironmentObject, the data model change triggers call of detail view's body. It turns out that the fooID binding in the detail view doesn't get updated at the time, and hence DataModel.get(id:) call crashes the app. I didn't expect the crash, because I thought the fooID binding value in the detail view would get updated before the detail view's body gets called. To put it in a more general way, the nature of the issue is that SwiftUI may call a view's body with a mix of up-to-date data model and stale binding value, which potentially can crash the app (unless we ignore invalid id in data model API code, but I don't think that's good idea because in my opinion this is an architecture issue that should be resolved on the caller side in the first place). I have two questions: Is this behavior (a view's binding value doesn't get updated when the view's body get called if the view accesses data model through @EnvironmentObject) by design, or is it just a limitation in the current implementation? In practical apps an item A may contain its own value, as well as id of another item. As a result, to show the item A in detail view, we need to access data model to get B's value by its id. The typical way to access data model is by using @EnvironmentObject. But this issue makes it infeasible to do that. If so, what's the alternative approach? Thanks for any suggestions. import SwiftUI struct Foo: Identifiable {     var id: Int     var value: Int } // Note that I use forced unwrapping in data model's APIs. The rationale: the caller of data model API should make sure it passes a valid id. class DataModel: ObservableObject {     @Published var foos: [Foo] = [Foo(id: 1, value: 1), Foo(id: 2, value: 2)]          func get(_ id: Int) -> Foo {         return foos.first(where: { $0.id == id })!     }     func remove(_ id: Int) {         let index = foos.firstIndex(where: { $0.id == id })!         foos.remove(at: index)     } } struct ListView: View {     @StateObject var dataModel = DataModel()     var body: some View {         NavigationView {             List {                 ForEach($dataModel.foos) { $foo in                     NavigationLink {                         DetailView(fooID: $foo.id)                     } label: {                         Text("\(foo.value)")                     }                 }             }         }         .environmentObject(dataModel)     } } struct DetailView: View {     @EnvironmentObject var dataModel: DataModel // Note: I know in this simple example I can pass the entire Foo's value to the detail view and the issue would be gone. I pass Foo's id just to demonstrate the issue.     @Binding var fooID: Int     var body: some View {         // The two print() calls are for debugging only.         print(Self._printChanges())         print(fooID)         return VStack {             Text("\(dataModel.get(fooID).value)")             Button("Delete It") {                 dataModel.remove(fooID)             }         }     } } struct ContentView: View {     var body: some View {         ListView()     } }

While verifying how binding invalidates a view (indirectly), I find an unexpected behavior. If the view hierarchy is list view -> detail view it works fine (as expected) to press a button in the detail view to delete the item. However, if the view hierarchy is list view -> detail view -> another detail view (containing the same item) it crashes when I press a button in the top-most detail view to delete the item. The crash occurs in the first detail view (the underlying one), because its body gets called. To put it in another way, the behavior is: If the detail view is the top-most view in the navigation stack, its body doesn't get called. Otherwise, its body gets called. I can't think out any reason for this behavior. My debugging showed below are what happened before the crash: I pressed a button in top-most detail view to delete the item. The ListView's body got called (as a result of ContentView body got called). It created only the detail view for the left item. Then the first DetailView's body get called. This is what caused the crash. I can't think out why this occurred, because it certainly didn't occur for the top-most detail view. Below is the code. Note the ListView and DetailView contains only binding and regular properties (they don't contain observable object or environment object, which I'm aware complicate the view invalidation behavior). import SwiftUI struct Foo: Identifiable { var id: Int var value: Int } // Note that I use forced unwrapping in data model's APIs. This is intentional. The rationale: the caller of data model API should make sure it passes a valid id. extension Array where Element == Foo { func get(_ id: Int) -> Foo { return first(where: { $0.id == id })! } mutating func remove(_ id: Int) { let index = firstIndex(where: { $0.id == id })! remove(at: index) } } class DataModel: ObservableObject { @Published var foos: [Foo] = [Foo(id: 1, value: 1), Foo(id: 2, value: 2)] } struct ListView: View { @Binding var foos: [Foo] var body: some View { NavigationView { List { ForEach(foos) { foo in NavigationLink { DetailView(foos: $foos, fooID: foo.id, label: "First detail view") } label: { Text("\(foo.value)") } } } } } } struct DetailView: View { @Binding var foos: [Foo] var fooID: Int var label: String var body: some View { // The two print() calls are for debugging only. print(Self._printChanges()) print(label) print(fooID) return VStack { Text(label) Divider() Text("Value: \(foos.get(fooID).value)") NavigationLink { DetailView(foos: $foos, fooID: fooID, label: "Another detail view") } label: { Text("Create another detail view") } Button("Delete It") { foos.remove(fooID) } } } } struct ContentView: View { @StateObject var dataModel = DataModel() var body: some View { ListView(foos: $dataModel.foos) } } Test 1: Start the app, click on an item in the list view to go to the detail view, then click on "Delete It" button. This works fine. The view hierarchy: list view -> detail view Test 2: Start the app, click on an item in the list view to go to the detail view, then click on "Create another detail view" to go to another detail view. Then click on "Delete It" button. The crashes the first detail view. The view hierarchy: list view -> detail view -> another detail view Could it be just another bug of @Binding? Is there any robust way to work around the issue?

Hi, I'm an individual developer in China. I signed up for my Apple Developer account last year (I input my name in both Chinese character and Pinyin when filling out the form). Then I successfully submitted my app to both China Mainland App Store and US App Store, but to find that in the app's home page in US App Store, my name was shown in Chinese character. That's quite a surprise. I think App Store should use my Pinyin name in US App Store (or perhaps better, provide an option to let me decide). The current behavior puts the China Mainland individual developers at a disadvantage because it makes it hard for them to prompt their apps in English speaking countries. Actually when one of my friends in US tried my app, his first comment was that I shouldn't show my name in Chinese character if the app is targeted for US users! I contacted Apple Developer Program support engineers twice for this issue, once last year, once recently. At the first time the reply was just boilerplate and useless. At the second time the engineer was quite helpful, although it was still impossible to solve the issue. One of the explanation the support engineer gave was that it's the government's requirement to use developer's legal name. But I'm not convinced because: 1) Using legal name doesn't necessarily mean it has to be Chinese characters. It can be Pinyin. For example, we have Pinyin name printed on passports and credit cards. 2) Since the app is submitted to US App Store, the information in the app's home page is supposed to be read by US people. It's common convention to show Chinese people name in Pinyin in this context (e.g., English documents). I'd think this is a deficiency in the design of the App Store. The support engineer said he would help to send my feedback. I understand how things work in big companies, so I think it may help to describe the issue in the forum also and hopefully someone can help to make the change, because it really doesn't make sense. Thanks!