Still getting this Error message... As I'm looking for a strange behavior, this was one of my suspects and I lost some time...
Post
Replies
Boosts
Views
Activity
About 1 week ago, I wanted to submit my App for review and I found this thread while trying to solve the impossible (5.5" screenshots of my app, which needs iOS 17+).
I decided to not fake these screenshots somehow, but created an image with Photoshop, consisting of a white background and the text "Devices with this screen resolution are not supported.
Minimum requirement: iOS 17."
My App was rejected because of some other rules.
Yesterday I requested the App
review again and guess what:
Screenshots of a 5.5" iPhone aren't required any more! I don't know, if Apple did a regular cleanup because of the iOS18 launch, or if my "screenshot" caused the removal, but finally they recognized, that it doesn't make sense to request screenshots of an antique device...
I have the same issue.
My new App supports iOS 17 (and later). How shall I create a 5.5" screenshot. There are no old devices or simulators with 5.5" display supporting iOS 17...
Same problem here.
Simple SwiftUI App on M1 under Rosetta. Now graphics code at all. Very annoying.
It seems like now I have found the real reason for this strange behaviour...
My App was a AppKit application before the migration to SwiftUI.
After some searching in the project settings I found under the macOS build target in
"Info / Custom macOS Application Target Properties" the key "Main nib file base name" which contained "MyApp.nib".
It looks like sometimes during the start of the App this file was searched and not found and sometimes maybe the start of the App was faster so it was not searched for...
However: After deleting the value, the error didn't reappear. Let's hope this is the final solution...
Unfortunately the problem was NOT solved...
I've got the problem again and it happens most of the time on my 2021 MacBook Pro (M1 Max) and not so often on my 2020 MacBook Pro (M1).
So it looks like a timing problem...
I found the problem :-)
During the initialization of the model of the @main view I did some longer running tasks to initialize some background processes.
Now I run them on a background task using perform{} and the bug is gone.
The reason why the bug appeared on my new, faster hardware obviously was the addition of more data structures to be initialized, so it took longer.
What???
I'm trying to delete some test containers, which clutter my dashboard and are not used anymore, and I don't find a way to delete them. After years, this is surreal...
I have this problem, too.
I can't find a "SwiftUI" way to open new windows having a different layout than the main window as action of a Button or Menu.
This is a very basic thing, so this should be possible in SwiftUI 2.
Re-tested after installing MacOS 11.0 Beta 7 (20A5374g).
The example code doesn’t crash any more, the bug seems to be fixed.
Thanks to all for testing and so giving me the hint, that it's a MacOS beta bug. :-)
Filed Apple bug report (FB8680646)...
Did 2 Checks now:
MacOS 11 beta (20A5364e) + Xcode 11.7 => Crash
MacOS 10.15.6 + Xcode 11.7 => no Crash
The bug is clearly in MacOS 11 beta...
Thanks for helping, even when there's no solution yet, but it's clear now, that it's not my fault... :-)
Did another check: I created a new, clean MacOS App project in Xcode, put the example code in ContentView.swift and exchanged the ContentView() in the App by MyView(). Then choose build profile MacOS and start. After that select the last entry and hit the Delete button and Boom, it crashes...
To reproduce, you have to select the last item in the list and hit the delete button. In my environment, it crashed 100% sure.
I'm using Xcode 12 beta6 on a Mac Book Air running the latest MacOS Big Sur Beta (build 20A5364e).