Post not yet marked as solved
@coopersita
For us it worked placing them at the same level as the other NavigationLinks already present in the same view.
Post not yet marked as solved
We updated our whole app and placed the empty NavigationLink in every view which already had a NavigationLink and it solved the problem for us :) Sad thing is that with the 14.5 being released, we will have to keep that thing in place for ages now even if 14.6 may solve it :/
Post not yet marked as solved
Same problem here. iOS 14.5 messed up the whole app navigation und now views are immediately popped upon being pushed so the App jumps around and is unusable. I fear this behavior will find its way into the release version as it is also present in the latest release candidate.
Update: Found a fix which is really weird but seems to work until the real cause is found:
In the pushing view that contains the NavigationLinks, add the following meaningless Navigationlink next to your existing ones. So far it seems the problem only occurs if you have more than one NavigationLink in a view and I am sure its related to the mentioned new behavior of 14.5
Add this to your view containing your existing NavigationLinks:
swift
NavigationLink(destination: EmptyView()) {
EmptyView()
}
Post not yet marked as solved
Just an update: Same behavior/bug in release version of iOS 14.2
So far we could not find any working fix for this. I think this really is a major/ciritical bug as users are wondering why their phones are getting really hot and the battery is draining like crazy :/
Post not yet marked as solved
I think I found the cause of the problem:
@Environment(\.scenePhase) private var scenePhase
If you want to detect app scenePhase changes as are available in iOS14, you probably added this line to your main swift file. The moment this line exists NFC stops detecting tags even if the prompt appears and the delegate method gets triggered.
My solution was to remove it and instead use for my purpose
@UIApplicationDelegateAdaptor(AppDelegate.self) var appDelegate
Post not yet marked as solved
I think I found the cause of the problem:
@Environment(\.scenePhase) private var scenePhase
If you want to detect app scenePhase changes as are available in iOS14, you probably added this line to your main swift file. The moment this line exists NFC stops detecting tags even if the prompt appears and the delegate method gets triggered.
My solution was to remove it and instead use for my purpose
@UIApplicationDelegateAdaptor(AppDelegate.self) var appDelegate
Post not yet marked as solved
Same behaviour in iOS 14 GM Version. CPU Usage goes up to 100% the moment you tap the Textfield and the Keyboard opens. It stays at 100% even after you closed the keyboard and navigated to different views.
Post not yet marked as solved
Error still persists in iOS14 GM. :(
Post not yet marked as solved
using:
.listStyle(SidebarListStyle())
should be all you need. But you meed to use negative padding or other tricks as this style has bit more spacing from all sides then the old version
Post not yet marked as solved
Update:
I think I found a solution! (At least until the bug itself gets fixed) ->
Try to add a second "OnAppear" modifier somewhere below the one you actually want.
VStack{
...
}
.onAppear(){
print("Works as usual - only fired on appear, even when navigation back to this view as expected")
}
.onAppear(){
print("Fired directly after onDisappear")
}
.onDisappear(){
print("Fired on Disappear as expected")
}
It seems like the second onAppear modifier always gets fired shortly after onDisappear, as reported here. If your add another onAppear modifier somewhere above, it will behaves initially expected!
So this may be a workaround until the bug is fixed, maybe it even helps in finding the cause of the problem.
If it doesn't work for you, try putting the second onAppear above the one you want, instead of below. In my tests one or the other seemed to work.
If this also doesnt work, try placing the second on Appear somewhere else in your view and debug/experient with which gets fired. For me usually one behaves correctly while the other one show the strange behaviour.
I guess it may be some parsing error of the swift document or its timing based problems which may be cause by how many States/Bindings you are referencing in the specific block.
Update 2: -> above solution doesnt seem to work as I initially thought
Further testing seems to point me towards the conclusion, that it's the code inside the onAppear, that leads to the behavior. Adding a second onAppear somewhere with a simple print works as expected, while my onAppear always shows the incorrect behavior regardless of where I place it. So something inside the onAppear, maybe the amount of code, or some specific references cause the problem
Post not yet marked as solved
Same behaviour on iOS 14 beta 8. OnAppear gets called after navigating via NavigationLink to a different view, which of course messes up the apps behavior
Happy to help, I didn’t have this problem yet, but I may in the future. I am sure Apple will improve SwiftUI in fix such special cases. Until then. We at least found a simple solution, even if it may not be perfect as you can see the list being empty for a second before it takes the new array.
Post not yet marked as solved
I heard about the performance problems and after some research a colleague and me got to a solution.: Currently. If you have a big list array which you try to modify, the list completely blocks the UI until it’s finished, which can take many seconds. To prevent this and work with thousands of entries without blocking everything, you just have to empty the list array and then fill it with the new modified array.So:Instead of a complicated workaround, just empty the List array and then set the new filters array. It may be necessary to introduce a delay so that emptying the listArray won't be omitted by the followed write.With a simple List like this and an "listArray" with your items:List(listArray){item in ... }Filter your array as needed and store the result somewhere. Then empty your original array! This way, SwiftUI won't do any comparisons and checks like it does when you just modifiy the array. After the array is empty fill it again with your new list. You probably will need a delay between those steps. I choose 100 milliseconds but a much lower number might also work. let filteredList = self.listArray.filter{...}
self.listArray = []
DispatchQueue.main.asyncAfter(deadline: .now() + .milliseconds(100)) {
self.listArray = newList
}With this simple method, the list will basically get rendered in the same short amount of time it usually does, even with tousands of items. Only downside is that you will probably see that the list gets emptied and refilled. But for now this ist the simplest and most effective solution I have found, until Apple manages to find a fiy for the perofmance issues.
My guess is your problem is that you are trying to filter the list directly or the array you pass to the list. Which leads to to whole thing being a big performance hog. Maybe try what Apple themselves showed in their WWDC videos: do not pass your array to „List(array){}“, instead create a List without passing anything „List{}“ and then inside the brackets do a for each with your array, where yo decide via classic SwiftUI „if“ when to render certain elements. This gives you multiple benefits and seems the be the recommended way in case you want to modify list content based on certain States. Apple used this method in their tutorials, to filter favorite items in a list if I remember correctly.Update: Ok, I made small test yesterday and this approach also didnt work. Will keep an eye on this in case soem solution comes into my mindUpdate 3: A collegue found a simple solution:Instead of a complicated workaround, just empty the List array and then set the new filters array. It may be necessary to introduce a delay so that emptying the listArray won't be omitted by the followed write.List(listArray){item in ... }self.listArray = []
DispatchQueue.main.asyncAfter(deadline: .now() + .milliseconds(100)) {
self.listArray = newList
}
