Switching "Allow Full Access" to ON in my custom keyboard's settings is causing a sigkill in the parent app, and the whole device to sort of lock up.
I can access the home screen, but tapping on any app icon doesn't do anything, except the app icon gets "stuck" as appearing highlighted. Restarting the device fixes this, and then the keyboard is useable and everything appears to be back to normal.
From searching around it appears that the sigkill is expected (the app is supposed to restart with the new "allow full access" setting, from what I understand), but the device locking up is what I'm worried about.
This is happenings on a physical iPhone 6s+ and the 6s+ simulator. Xcode version 7.3 (beta).
While you are on debug mode and changing keyboards Full Access, it will cause the crash of extension but while you are release it will work just fine, please check it and give a follow up.
Related
I launched an app with my own iphone7. the app had nothing on it. It is a single page application in IOS. when I ran the app it made my phone's screen go black. I can still get messages and it makes sounds, but the screen is black so I can not use it. How can I fix it?
I assume you're still running the app itself, and because your app has no content, it shows a black screen by default. If that's the case, you can forcibly terminate the app by double-tapping on the Home button, and then swiping down on the problematic app.
As an alternative, you could try soft resetting the device itself, by holding the Sleep button and the Home button at the same time for 10 seconds.
As a last resort, you can hard reset the device under Settings -> General -> Reset -> Erase All Content And Settings. Note that this will erase everything on the device, so should only be attempted if nothing else works.
Is the iPhone "device Home button" (circle button that is part of the hardware at bottom center) the standard way that users exit an iPhone app?
I don't have an actual iPhone device yet (looking for the iPhone6 to come down in price a bit), am just working with Xcode simulators. When I run my iPhone Swift apps, they are always in full screen mode.
On Android, there are a few navigation buttons built into the OS that appear at the bottom of the screen - Back, Home, Open Apps. And in that OS you can give a directive to exit full screen to reveal those OS buttons.. which then allows the user to easily exit the app if they'd like to.
In looking at the iPhone apps on the simulator, I notice they don't have this kind of UX.
What are the best practices around iPhone users
A. Sending an app to the background ?
B. Quitting/Closing an app ?
To send an app to the background, hitting the home button is sufficient.
To quit an app, tapping the home button twice shows you all the open apps; you can then swipe an app to "kill" (terminate) it.
However, here is a recent post by the excellent John Gruber explaining why killing an app should only be a last resort: https://daringfireball.net/2017/07/you_should_not_force_quit_apps
Note: on the iPhone Simulator, the command-shift-H key combo is equivalent to hitting the home button.
To send an app to the background:
Press the Home button.
To "quit" or "close" an app:
Press the Home button.
That's all the UX expected of an iOS app... and none if it is actually provided by your app. iOS manages it for you; you just have to deal with your app's lifecycle methods to respond to the user leaving and re-entering your app.
iOS doesn't expect users to know or care about the difference between "background" and "closed/quit" in most cases. You enter an app, you leave an app, that's it.
And the way iOS works under the hood, there is no difference in most cases — when you leave an app, it's not "running in the background", it's "frozen" or "suspended": that is, in memory but not running. That way the OS can get it usable again near-instantly if the user comes back, or instantly reclaim that memory if another process needs it.
The user can also invoke the multitasking UI (double click home button, or in iOS 11 on iPad swipe up from bottom edge) and swipe an app away, but this is equivalent to the "kill" or "force quit" actions seen in other operating systems — it's primarily for situations where an app is misbehaving. This isn't part of your app's UX either; it's also provided by iOS.
As noted in the Daring Fireball post linked from #TimKokesh's answer, there are some circumstances where an app "in the background" isn't "frozen" but has some limited ability to run, the Settings app has UI to help the user keep tabs on what are using (and abusing) that ability, and those are some of the only cases where it's reasonable for a user to "force quit" apps.
If you want to have a real iPhone look-alike simulator on your development environment, yes it's available with New Xcode-9/Beta version. It shows real hardware buttons(volume, lock, home buttons) which you can press and feel like a real device. If you are interested you can download it from here
On other Xcode environments, you can go to home screen by pressing the keys: Cmd + Shift + H
When the scheme is running, the iPhone screen stays on. The bug that I'm trying to reproduce only occurs when the screen goes to standby by itself. When stopping the running scheme, I don't have breakpoints anymore.. So I'm looking for a way for the screen to go to standby by itself, but it has to stay connected to the debugger. When using the physical button, the bug does not occur.
Many thanks guys!!!
When my app is running on simulator and I press the home button it enters the background properly. But when I put the app back in the foreground, it has apparently dropped all the managed objects in memory, and the app crashes when I try to resume using it. There's no code in the any of the callbacks for the app changing state that would cause that, and the app has never displayed this behavior before.
What changed was going to xCode 6 / iOS 8 on the simulator, and I also applied "Reset content and settings" in response to this problem.
The app behaves problem-free on actual devices, both iOS 7 and iOS 8. Is this another bug with the new iOS simulator?
If you did "reset content and settings" with the app in the background, you probably blew away all its context. You should terminate the apps in the background before running that.
I'm creating a new app. Very, very initial stages (i.e., it literally has no custom code yet). All I've done so far is a basic implementation of Urban Airship's libraries.
Sometimes (about 50% of the time?), when I push the app to my device, the following occurs:
App doesn't load on device
Xcode reports "failed to get task for process"
Device exhibits odd behavior.
"Odd behavior" includes:
Device wallpaper disappears and is replaced with an all black background.
Tapping on any icons gives them a pressed/shadowed look, but nothing happens.
Tapping on the icon again sets it back to its normal state. Again, nothing else.
Pressing home button does nothing.
Pressing lock button will lock device, but no attempt to unlock the device (home button or lock/unlock button) has no effect.
Attempting to use Siri gives the initial sound, but nothing further.
Hard rebooting the device gets it functional again. There doesn't seem to be a pattern to when this "bug" appears.
Has anyone else encountered this "bug"?