I have a tableView with a few sections. When I remove all rows from a section, I also remove the section with the UITableViewRowAnimationTop animation (so it slides up). When running the app on an iOS 4 device, the deleteSections: withRowAnimations: method correctly makes the section slide up and disappear behind whatever is above it. However on iOS 5, the section slides up but stays infront of whatever is above it, then disappears once it's finished sliding. What could be wrong?
FYI: I'm using iOS5 but have changed the iOS deployment target to iOS 4.0, so my app will run on all iOS version from 4 upward, and have changed the architecture to armv6 armv7
EDIT: For testing, I created an empty project with just a UITableViewController, which had a couple of sections with a couple of rows in each, nothing fancy. Got the same behaviour, so although I'm really hesitant to do this (because it's almost never the case), I'm going to go out on a limb and say this is a bug in iOS5?
Having a similar problem. Popping a view controller where the animation is supposed to slide the prior view in from the left (works fine on iOS 4). But on iOS 5 the bulk of the page appears immediately while only the bottom tab bar slides in from the left. Have single-stepped through the code on both versions and it appears to be taking the same path right up to the popViewControllerAnimated call.
Unfortunately this is a very complex app (unnecessarily complex, but that's another story) where most of the screens are dynamic, so it's hard to simplify down to a test case. No obvious solution so far.
Related
I’ve been struggling with a bug since I changed the version of Xcode 10.3 to 11 beta and iOS 12 to 13.
This bug is related to UIVisualEffectView and the value of the blur changing while navigating through the App.
Basically It’s a bank App where the user has the possibilty to choose the visibility of his balance
In the first view therefore the first view(DashBoard) has a view with the user balance where he can
Hide or unhide it. As you can image to hide the balance we are using the UIVisualEffectView with blur effect.
Where the view is settled in a Xib and linked to the class keeping it’s reference by outlet.
Everything works fine when we open the app for the first time and we see the blur covering the balance 100 %
Not giving the possibility to the user to see it. The user can see it only if he touch on the view and switch to the
visible option.
If the user goes out from the app or present another view over the dashboard ( the view holding the blur area )
Each time the user comes back to dashboard the blur decreases its value. It happens only if the user close and open the app or if the user presents some view over the dashboard and come back.
Everything worked fine in iOS 12 but in iOS 13 it decrease along the interaction the user is having with the app and turning back to the dashboard.
Compiling the app in iOS 12 with Xcode 10.3 I observer that the value of filters.gaussianBlur remains the same
If the user present view over the dash board going around and coming back. I mean ( THE BLUR DOESN’T CHANGE FOR ANY REASON )
While compiling the same code with the same logic without change anything in Xcode 11 with IOS 13 the value of
filters.gaussianBlur.inputRadius decrease randomly until comes to 0 and showing all the are that should be hidden.
I can understand that is a weird behavior because everything works fine in iOS 12 but while changing version the value starts to decrease while the user is going around the app and turning back to dashboard until the user be capable to see the balance without touch on it.
I don't think it's necessary to show any code because the behavior works perfectly well in iOS 12.
But if necessary I'm open to post it.
Here I have some picture of this behavior
If you observe the value remains the same always 20. (USING IOS 12)
Here the values decrease until arrives in 0 ( USING IOS 13)
These is the behavior I'm getting while presenting views over the dashboard and coming back.
I solved this problem by updating the instance of the UIVisualEffectView each time the viewAppears. So I’m not using outlet anymore. I’m creating a new instance and adding it to the view after remove the previous one. It’s a good work around but I think it’s a bug in iOS 13 that apple should take a look.
We have an app that has been around since before the days of storyboards. Prior to iOS 11 everything was fine after we updated it to be 64 bit. We have found two issues when running under iOS 11:
On iPhones the single UIBarButtonItem in the navigation bar's RightBarButtonItems isn't being placed all the way to the right as usual (the left side buttons is in the proper position).
On iPads we have what looks much like a segmented control (but made of individual buttons). It works fine when it is not in any kind of bar, but when it is in a bar it doesn't get touches.
In both cases I have used the UI navigator in Xcode to see that iOS 11 has added a couple extra views between bars and buttons. One of the added views is a bar content view (specific class depends on wether it is a toolbar or navigation bar; _UIToolbarContentView or _UINavigationBarContentView). The other added view is consistent among all kinds of bars, _UIButtonBarStackView.
In issue 1 above the added stack view is adding a very wide zero height view after the right bar button that is pushing the button way to the left (like it is trying to fit on an iPhone 4's screen far). Since the class has an underscore in front of it and isn't listed in the docs it must be a private class so even if I did dig into it and figure out how to keep the extra padding from getting added to the end it would get rejected by Apple for using private API.
I can't be sure what of the new views is intercepting the touches for the second issue but given that they are the only real differences I see between iOS 10 & 11 they seem the most likely culprits.
As I mentioned this was built before storyboards so the UI is built in xib files.
Has anyone run into issues with these new views and found a way to solve them? Or should I just rip out the whole UI and rebuild it?
I have issue when I try to push view controller in willTransitionToPresentationStyle:. The view was blinking for a split second before it fully expanded. It might be a small glitch or bug since iOS 10 and Xcode 8 are still in beta. But when I manually requested to change presentation style to MSMessagesAppPresentationStyleExpanded by calling requestPresentationStyle: after I push view controller, it went to expand mode more smoothly. Does anyone have similar issue?
I have had similar problems with transitions in iMessage apps. I think this should improve considerably when iOS 10 and Xcode 8 come out of beta, but for now we have to deal with Xcode's bugs.
There's a few things I've done to make this look better. Inside my extension I have a method that checks the presentation style every time the view changes. This method manages two different UIs - one for MSMessagesAppPresentationStyleExpanded and one for MSMessagesAppPresentationStyleCompact. This method hides and shows specific views accordingly. In my compact UI I have a button that allows the user to expand the interface by clicking it (this is basically the same as clicking the up arrow at the bottom right of the screen).
I've noticed that if you let the user expand the messages app after the view has been loaded for a while the transitions are much smoother and less buggy. Not sure why this is the case, but you should give it a try. Also, I've found segues to be extremely buggy, so that's why I went with keeping everything on one view controller.
I'm developing a WatchKit app for the Apple Watch. I "finished" the app originally when the first beta was out back in Nov/Dec.
I recently upgraded the the final release and somethings in WatchKit changed (as to be expected). I had to fix couple lines of code here and there since they changed how the app views start up.
Anyway, after fixing the issues I noticed that my WKInterfaceTable displays and scrolls almost correctly. The last row in the table gets cut off (as indicated in the screenshot below). Also, the scrollbar is very short - shorter than it should be (also in the screenshot). Anyone else experiencing this?
In the screenshot, the app has about 10 rows, I just scrolled way to the bottom with a bit of an extra pull just to show the cut-off from the last row... Notice the bottom of the row and the scrollbar at the top right.
I've included extra screenshots that may be helpful. I researched some tutorials on WKInterfaceTable and they're not really doing anything different than I am in the Interface Builder. I'm lost here.
I'm not making ANY UI modifications in code. I'm just letting WatchKit handle the UI as much as possible without any intervention from me.
Thanks!
Other Screenshots:
The scrollbar is short by design, this isn't a bug. That's how it's meant to be.
Regarding the cutting off of the last row, add the table into a WKInterfaceGroup, then set the group's height to 'Size to Fit Content'. That should fix it.
I build my app in Xcode4.6 and run it on iPod5 with iOS7.
The table view is grouped, all cells are standard. Table is in editing mode for one section.
There is a very weird glitch on cells which are in editing mode. Problem is shown on the screenshot (with glitch and normal).
This "thing" appears only for a moment, I am able to catch it only in dispatch_async from viewDidAppear. Then after a moment it disappears by itself and all comes to normal (cellForRowAtIndexPath, layoutSubviews in cell are not called, I'm not reloading the table! - weirdest thing).
My table and cells are pretty complex, but I digged down and removed all unrelevant views.
Here table is transparent, red is color of the view behind it.
I have set cell.contentView.alpha to zero (all my views are added to it), and cell itself is green.
I tried cell.alpha = 0, in this case cell is not showing and there is no glitch, so it is definitely problem with a cell.
Please write any suggestions, I ran out of ideas. Thanks.
UPD. It appears that this only happens in edit mode. If I don't set it to YES, everything's ok.
UPD 2. The glitch appears when [table setEditing:YES] is called. If animated, it shows that this thing expands to a normal width of a cell and becomes normal.
I'm starting to think that it's unsolvable (obviously Apple won't fix it)
Since I asked this question I have noticed this bug in many iOS6 applications in AppStore.
I assume this is a bug with iOS6 apps built on Xcode4 that are run on iOS7 in compatibility mode.
I do not use Xcode4 anymore, and I don't support iOS6 in my apps.
So this question is neither relevant nor worth solving.