On the face of it, FamilyControls are not part of SwiftUI, so I don't see why they couldn't be used without it. Having said that, FamilyActivityPicker conforms to View, which is a SwiftUI component. In UIKit code, you could create the FamilyActivityPicker, but because it's a (SwiftUI) View, you can't directly add it to a ViewController. You would have to use a UIHostingController, which is the generic solution for adding SwiftUI to a UIKit app.

What kind of connection is it, between the Mac Mini and the Dell monitor? What cable?

Yes, this is a known issue. Some people have reported success using Network Link Conditioner from Xcode 12.5.1

iOS 15.0.1 is available now. One of it's fixes is: "Settings app may incorrectly display an alert that storage is full"

50gb?

All we have to work with is the PHPickerViewControllerDelegate, which gives us the single method: • picker(_:didFinishPicking:) This passes us: • results: [PHPickerResult] ...and we can look at this, to get an array of NSItemProvider, then get our images. However, there is no information on what order was used, when picking the items. So what you want to achieve is not possible with PHPickerViewController. You would have to create your own (more advanced version of) PHPickerViewController.

On the far left, in the gutter, I get a vertical blue bar. Clicking that shows the option "Discard Change" Is that what you want?

It looks like you have mis-spelled "inputImage" as "inpuntImage". Your error message is actually: "Cannot find inpuntImage in scope"

Geoff Hackworth has an excellent analysis of the issues here... "How iPad Apps Adapt to the New 8.3" iPad Mini" https://hacknicity.medium.com/how-ipad-apps-adapt-to-the-new-8-3-ipad-mini-7796efdc88eb

This is not possible (without jailbreaking).

And here (finally?) is Apple's statement on the need to recompile full-screen apps for the iPad Mini 6: ...if you’ve added UIRequiresFullScreen=YES to your app’s Info.plist in order to keep your app full screen during multitasking, you’ll need to recompile with Xcode 13 and the SDK for iPadOS 15 to take advantage of the full screen size See https://developer.apple.com/news/?id=oefg5bhp&1632770922 Otherwise, your "full-screen" app will be displayed with black bars. So the answer to my original question... Do I really have to go back to my apps, and add scrolling, or trim the content? For full-screen apps: Recompile with Xcode 13 and the SDK for iPadOS 15 Resubmit to the App Store

@syedtarq As a retired FireFighter, I strongly reccommend that you deal with your swollen battery as soon as possible! It is a fire risk, and will continue to be a fire risk, whatever you do with it. Please dispose of it in a safe way (e.g. take it to a specialised recycling center), as soon as possible. No kidding. Safety first. Once you have a laptop with no battery in it, then look at your options.

I see two separate issues here. Firstly, the display of Picker labels, and Pickers themselves, is platform-specific. This code will behave differently on iOS and macOS. (Hint tag your questions, to make the Platform clear to helpers!) On iOS, the label, which is Text("Select Favorite Fruit"), will not show. On macOS, it will. But is that what @RadApps is asking about? Or do they mean... An obscure UI bug, where, after using the Picker to select, the selected item does not show correctly. I can reproduce this. It is fixable by adding some content above the Picker... ...or even by adding some padding to the top of the Picker, like this: struct ExampleView: View { var fruits = ["Banana","Apple", "Peach", "Watermelon", "Grapes" ] @State private var selectedFruit = 0 var body: some View { VStack { Picker("Select Favorite Fruit", selection: $selectedFruit) { ForEach(0..<fruits.count) { Text(self.fruits[$0]) .padding() } } .padding(.top, 20) /// Workaround for obscure UI issue .pickerStyle(MenuPickerStyle()) Text("Your Favorite Fruit: \(self.fruits[selectedFruit])") } } }

The "version" number and the "build" number are two separate things. You can submit a new build with the same version number (3.4.0), as long as you increase the "build" number (which is usually a single integer). I always expire old builds, but that is just my preference, it is not a requirement. It is possible to have multiple builds with the same version number, and different build numbers, and these can all be available on TestFlight. Then you just choose the build you want, for Production.

On App Store Connect, the iOS and macOS versions are published separately. So you can choose one of them, and remove it from sale. The other version is not affected. Go to "Pricing and Availability" > "Availability" Select "Remove from sale" "Save" (There may be a delay, before the app is removed from the App Store)