That doesn't work for me, depending on the background image used. While my example worked fine with three different images (square, portrait, and landscape images), your new version doesn't work for my landscape image. I get a white area to the right when the Simulator/Preview is in Landscape Left. If you don't need to use an image, you could use a plain colour or a gradient: let gradient: LinearGradient = LinearGradient(gradient: Gradient(colors: [Color.init(red: 200.0/255.0, green: 200.0/255.0, blue: 250.0/255.0), Color.init(red: 125.0/255.0, green: 125.0/255.0, blue: 175.0/255.0)]), startPoint: .top, endPoint: .bottom) struct ContentView: View { var body: some View { ZStack { gradient .ignoresSafeArea() ScrollView { VStack(spacing: 32) { ForEach(1..<20) { i in Text("Line \(i)") } } } } } } Just an idea. Don't have to do everything I say 😄

When Apple release a new beta and an app doesn't work, it's likely because that app is doing something that has changed in the new beta. It is up to the app developers to make their app work with the new version of iOS. You should get in touch with them, not us. (We're not Deltek developers, and we don't work for Apple.)

I think you're looking for something like this: import SwiftUI struct ContentView: View { var body: some View { ScrollView { VStack(spacing: 24) { ForEach(1..<20) { i in Text("Line \(i)") } } } .frame(maxWidth: .infinity, maxHeight: .infinity) .background( Image("background") .resizable() .scaledToFill() .ignoresSafeArea() ) } } #Preview { ContentView() } The main difference is that my code adds a background to the ScrollView rather than putting everything on top of an image via a ZStack. When you do it your way, you've kind of told everything on top of that layer how big they'll be, which is why your ScrollView is distorted, and bits of it disappear off the screen.

These are the Developer Forums, where developers of apps for Apple's platforms ask each other for hints and tips on coding. Your question is more of a product support one, so I'd suggest you ask it over at the Apple Support Forums. Thanks.

These are the Developer Forums, where developers of apps for Apple's platforms ask each other for hints and tips on coding. Your question is more of a product support one, so I'd suggest you ask it over at the Apple Support Forums. Thanks.

It depends on what the IAP gave the customer. If the IAP unlocked something and you're now going to lock it behind a subscription, then no, you shouldn't do that. You can't say to someone, "Pay me $5 and you get Feature A," then some time later say, "Actually, I'm taking away Feature A unless you pay me $5 every year". If, however, the IAP gives a feature that is not going to be locked behind the new subscription, then you can create the new subscription and customers can decide if they want to buy it. Any customers who already bought the IAP should still retain the features it unlocked. In general when doing this, you need to put new features into the subscription and leave previous IAPs as they are. You can remove them from sale so no one can buy them going forward, but anyone who already bought the IAP should retain those features going forward. Or, you could offer previous IAP purchasers a discounted subscription price. So, two subscriptions, one for new customers who have not previously purchased the IAP, and one at a lower price taking into account what they previously paid for the IAP, e.g.: IAP: $5 New sub: $10/year. New sub for IAP purchasers: $8/year. You have to figure out what works best - but you definitely shouldn't annoy your existing customers, or you'll find out you don't have any.

These are the Developer Forums, where developers of apps for Apple's platforms ask each other for hints and tips on coding. Your question is more of a product support one, so I'd suggest you ask it over at the Apple Support Forums. Thanks. System data is the System, i.e. iOS plus necessary files such as logs and cache files. That number will stay pretty static. There's not really a lot you can do to reduce that. Try and offload some of your data to iCloud. Enable iCloud Photos and turn on "Optimise iPhone Storage" in Settings > Apps > Photos. Regardless, you have a 64GB iPhone, which isn't that big these days. It might've been fine five years ago, but not really now.

You should probably raise this as a bug in the usual way. It won't really get progressed if it's only posted in these Developer Forums. You need to raise each issue you find separately at https://feedbackassistant.apple.com/ You can post the FB numbers here if you want, so that others can link to them.

You don't have to create an entirely new thread just to make a small change to your original post. You have a one-hour window to make changes, which you are still within. I'm marking this as a duplicate.

Why do you need to build a framework with an older version? What's the technical reason you can't build it in macOS Sequoia with Xcode 16?

You should probably raise this as a bug in the usual way. It won't really get progressed if it's only posted in these Developer Forums. You need to raise each issue you find separately at https://feedbackassistant.apple.com/ You can post the FB numbers here if you want, so that others can link to them.

There are tons of online resources to learn how to code in Swift. Apple's own sample code is extensive and allows you to follow along. https://developer.apple.com/swift/

Isn't it just a normal TextField? Maybe with a placeholder? Show us the code you've tried, properly-formatted with the code formatting tools in the toolbar.

Yes. I was using an M1 MacBook Air 2020 with 16GB and 1TB SSD. Never had any issues. You're on the M4 chip. You'll be fine for years.

All my apps work on both the iPhone and iPad, but due to the amount of changes - some structural - that are required to get an iPhone version to look and work properly on the iPad, I use two different views: @main struct MainApp: App { // ... var body: some Scene { WindowGroup { if(UIDevice.current.userInterfaceIdiom == .pad) { TabletView() } else { PhoneView() } } } } So, if the user is using an iPhone, the PhoneView() is the main entry point. For iPads, it's TabletView(). The reason I did this is because the iPad has much more space and allows me to do more things, so the TabletView has more things in it. Also, I'd rather not have one big, unmanageable View full of if ... else statements and ternary operators. It also means your spacers and padding values apply only to that device type. Where the two views have similar UI, those bits are extracted into their own little View structs and called within those two main entry points. When you separate out the two views you may find you're duplicating some work, but you'll also be working on a view that only applies to an iPad or an iPhone and not both. You can make a change in the TabletView and be assured it hasn't affected the PhoneView, so you haven't got to retest that change on the iPhone. You can also then expand this to include Vision Pro, Apple TV, and any other device idioms Apple has or releases in future, and you won't need to add more and more if ... else and ternary operators in that one massive file. If you're having issues with specific models of an iPad or iPhone I'd say you're maybe using too many magic numbers in your code? You've probably found that the padding on an iPhone 13 mini for some label is 5, while on an iPhone 14 Plus it's 12 so you've written that in. You should rework this to align things naturally using SwiftUI's HStacks, YStacks etc. Or, have a consistent padding for your UI so that it looks the same on every device. Let's say you can fit 8 text fields vertically in a form on an iPhone 12 mini, and 10 on an iPhone 15 Pro, that's fine. You don't need to space everything out to always fit 8 fields on the screen, so the padding between the fields can be the same on every device. If you want to show us an example of what's causing you issues, drop some code here (properly-formatted using the code formatting toolbar) and screenshots showing us the issue in the UI so we can visualise it.