Does this age reporting requirement apply to TestFlight apps?

I did find that iStat menus has a setting to "Combine Processes" so it's creating sort of a compilation that explains why ActivityMonitor is different. Still, if all these simulator processes add up to 10GB it still seems like a lot.

Yes, I do believe a widget similar to the clock widget would definitely serve my purposes. And I see that widget works on iOS 15 and 18+ which is also what I want Is there an example app that Apple has that shows how to create that list within the widget? I may need to read through more doc's to learn how to do this. Thanks so much for your answer!

One idea I thought of would be to add a flag to my CoreData that allows one date to be selected as "widget ready" then the creation of the widget could pick that up. I'm not sure this is "better" than just creating a iOS 16+ intent that allows a date & description entry as the widget is being added. One feature that would be really useful would be if the same date is selected as one that's in the database already, then the description text from the database could be offered as a default. I have no idea how I'd go about that but it sounds useful.

Oh look - it's back now in Xcode26 😏 Maybe this post could be removed by a moderator - to help keep people from finding it a good part of a decade later 🙏

My latest trick is to NOT use Safari when unlocking my developer account. Use a different browser - when I tried Chrome I get different options most times at the same points in the login.

When I went back to this - it doesn't seem like the .icon ever never worked at all. For now exporting the 3 files and putting them in the 3 spots in Xcode works for me. When I go to customize in the simulator (I don't have a device on iOS26!) it does pick up the right icons. Looks like my attempt above to match up file names failed, trying again. Icon Composer button = IC file name = Xcode name Default =*-iOS-Default-1024x1024(at)1x.png = Any Appearance Dark =*-iOS-Dark-1024x1024(at)1x.png =Dark Mono=*-iOS-ClearLight-1024x1024(at)1x.png=Tinted

OK I found out how to do it - but it doesn't fully work. When you save the file in Icon Composer - THAT is the .icon file! 😲seems obvious after you know that. Don't drag it into the Asset Catalog - like you have for years and years. Just drag it into where your other files are. It will turn into an .icon. Unfortunately, All I see is the main icon. The Dark one is definitely NOT what I saved.

They said Xcode will just read the .icon file so I assume this is only on macOS 26. I'd love to hear a confirmation of that - I'm not going to load Beta macOS. Beta Xcode was a big enough step for me. Someone asked in the group lab if the .icon files were back portable. The answer was "Yes" but I think what they meant was you can use the output of the Icon Composer back in older Xcode because they are just PNG or SVG files. (whatever you imported) I seem to remember never coming back from deleting the AppIcon asset. It's in the back of my mind as a "Bad Idea"! I think I created a new project and copied all my files back in. Probably I didn't have a recent enough commit. Xcode 26 Icon Composer Any Appearance Default Dark Dark Tinted Mono

I figured it out: click on the document icon at the top of the right sidebar, then under platforms turn on iOS only. ( I turned off watchOS too) Then in the Export (⌘⇧E) pick iOS and change the Scale from 2x to 1x (and hit return - or it won't take effect) Then hit Export and pick your name & location. Do this again for the other 2 icons. Drag them individually into Xcode. Still doesn't answer why I don't get a .icon file. Maybe this only works on macOS 26. I'm still on macOS 15. You can store individual art and setting in each of the icons which is great. I don't see how to get the simulator to show tinted icons but I do see it switching to my Dark one.

I guess my original question was answered by @deeje - I'd accept that answer but NSCompoundPredicate was spelled wrong🤓 https://stackoverflow.com/questions/31708540/swift-combining-predicates is useful reading on the topic. My follow-on question of how exactly to do that is mostly answered by "the data you compare must have the same type". My desire to add this functionality is now lower than my desire to figure out how to get SwiftUI to do this in the spot I need it. The basic Int(dateVariable) was met with some compiler error I didn't dig into.

Thanks for the quick answer! Is "dateFromText" some sort of function somewhere? The compiler says it's out of scope and I don't find it in searches. I don't want to type the entire date in the search so the == seems not in the direction I want to go. I likely need to read more up on predicates before I'm ready to create this feature. I was thinking that I could type any character or word in my list and it would find that. Like if any of the dates were 2022 - I could type 22 and it would find that. It seems like I'd have to convert the date back to text to do that. Then there's the problematic issue with date formatting where a search of 22 might find the 22nd of a month in addition to the year and then there's numeric months vs. spelled out in long format...

Thanks for the quick answer! But my question evolved since I wrote this: While the predicate I created (quoted above) for searching a String works great. My other attribute is a Date, but when I try to search on the date field nothing works: .searchable(text: $searchText) .onChange(of: searchText) { _, text in evnts.nsPredicate = text.isEmpty ? nil : NSPredicate(format: "eventDate CONTAINS %i " , text ) also %@ doesn't work either I did read up on CompoundPredicates here: https://stackoverflow.com/questions/31708540/swift-combining-predicates But since one of my predicates doesn't work on it's own, I don't see how combining them will magically work.

I can see that both .tint & .accentColor works for the default picker. But is there any way to change the color of a .pickerStyle(.wheel)? I've tried a lot of scenarios. It only seems to work with .automatic. Picker ("", selection: $countDowns) { ForEach(countDowns, id: \.self) { countDown in Text(" \(countDown)") // .accentColor(.blue) } } .accentColor(.blue) // .tint(.blue) // .pickerStyle(.wheel) .font(.largeTitle) .scaleEffect(2.0)

I asked about this in a WWDC24 lab. I didn't get any real recognition that this is a big accessibility problem. They did recommend NOT creating 2 layouts that shift completely when going from portrait to landscape as that would be very disorienting. SwiftUI by design is meant to flow naturally when shifting orientation. Essentially the answer was: work on constraining and spacing things to fit as best as you can. The impression I get is: If you have to lock your app to one orientation or the other that's probably fine. There are some very highly regarded apps that do that.