What types of restrictions is there when adding a custom keyboard or numpad in an app?
I know that some apps requires you to enable keyboards in your system settings.
I recently saw an app using this keyboard:
The app does not require you to activate the keyboard. So how can I make my own custom numpad like this one?
Feel free to share any tutorials/libraries
thanks,
There's a great swift keyboard/calculator tutorial out there that will serve as a starting point for what you're doing:
http://code.tutsplus.com/tutorials/ios-8-creating-a-custom-keyboard-in-swift--cms-22344
In terms of "restrictions", you can add the keyboard to the parent app without any problems. If you want to make your keyboard available in OTHER apps, then you will need to adhere to the restrictions that Apple lays out on this page: https://developer.apple.com/library/ios/documentation/General/Conceptual/ExtensibilityPG/Keyboard.html - search for "trust"
Swift and Xcode are both moving targets that are updated more often than a project can be completed! So be ready to deal with constant updates as you go through the learning curve. Sometimes the time it takes for a client to approve something is enough time for the Swift/xCode/iOS paradigm to change enough to require you to "fix" things that already worked before submitting for approval. Just row row gently down the stream.
Related
I have a button in my app that brings up the system app settings UI. Instructions are given around the button.
I want to provide further instructions to the user via a toast message after the settings page shows up so they know exactly what to do. It's not a super intuitive setting, related to notification style, and such instructions would be a lot clearer when the user is actually on the settings page.
In Android, this is easily done via toast.makeText().show(). The resulting toast would have no problem going on top of the system settings UI.
In iOS though, I've looked up several guides, mostly using the UIView animation. The problem is, the resulting toast window seems to only work inside the app itself. It cannot go on top of the system settings UI.
Is what I want to achieve technically possible in iOS?
No. You are sandboxed; Settings is a different app and you cannot impose anything on to its interface.
If one writes a custom app is it possible to be able to add a shortcut to the iOS lock screen? Or is that reserved for Apple sanctioned apps?
Currently, one can go into settings and add, say, the voice memo app to the lock screen control center. Of course, these shortcuts are available when you've signed in as well (by getting to the control center).
I like to use React Native and Expo, but my question is more general than that (but let me know if you know of any Expo tricks for this).
I'm trying to create a slider like this:
Is there a UI Element I can use in order to achieve this? Or another way?
No, there is no direct UIElement available which will give the desired effect.
If you plan to release the app on AppStore I would suggest do not try to replicate slide to unlock / power off.
I had a app rejected exactly for this reason. Following is the rejection reason as given by Apple.
Specifically, the Slide to Start element is not appropriate
and not in compliance with the App Store Review Guidelines as it is
too similar to the iOS Slide to Unlock UI. While we understand this
specific UI element is not present in the current version of iOS, it
is still not appropriate to include it in your app.
I had this same UIElement approved in an earlier version but got rejected during an update. So there is a small chance it gets over looked.
I want to design my own custom input view keyboard using a custom keyboard extension in swift. The existing Xcode 6.1 default set of keyboards do not fit my app needs. What I want is an enhanced number pad which I would modify, like in the Soulver app in the iOS app store. http://www.acqualia.com/soulver/iphone/
Ultimately I do not need a custom keyboard extension to offer to other apps but I do not mind if my app offers one. It looks to me like custom keyboards are the right place to start for for a custom input view keyboard.
I finally just about have digested constraints in the editor and would like to make use of a storyboard or xib.
I do need to be able to programmatically select the keyboard extension within the app.
The keyboard/custom view needs to be available to the app that contains it without activation in iOS settings.
Can this be done as an extension given the requirements, or can the custom keyboard extension be easily converted to a custom input view? Can you illustrate either one or point out sample Swift code I missed when searching? Thank you.
I am writing a keyboard extension in Swift right now and highly recommend not doing the same. Both Swift and the Keyboard Extension API are brand new, not well documented, creating significant learning curves, and both have significant bugs or weird implementation details to work around.
From the way you phrased your question it doesn't sound like you are very experienced in iOS development, and attempting to learn too many things at once is a recipe for disaster. If I could do my current project over, I would have done it in Objective C just to vastly simplify what I was learning.
But the good news is that you don't need the keyboard to run in other apps. This is good news because writing a custom input keyboard class within your own app is very simple and easy, and a great place to start. There is a good deal of existing documentation on how to do so, including this excellent post on stack overflow.
How do I retrieve keystrokes from a custom keyboard on an iOS app?
More detail:
The standard custom input view API in cocoa is very powerful, the one in the keyboard extension is almost entirely neutered, so you can do far more with a custom input view than you can with a keyboard Extension. To activate a keyboard extension requires getting the user to turn it on in their iPhone settings, there is no way around that and no way to pick which keyboard they choose within your app (other than to not allow custom keyboard extensions at all).
If you need to access the internet or data within your app for any reason (tracking usage information, activating an in-app purchase, accessing preferences) you must also convince your user to turn on "Full Access", which presents an incredibly scary alert that reads to users as if turning it on means you will be able to spy on them and steal their passwords
Getting back to why you don't want to use Swift in an extension. First, Objective C doesn't cause Xcode's code parser to crash many times a day, while developing in Swift does, sometimes crashing Xcode itself. In Objective C the debugger is almost always correct, in the current version of Swift often you can't see array or dictionary contents, sometimes what it shows is inaccurate, and when stepping through code often takes nonsensical routes. Developing in Objective Code means you won't have to update your code because of changes to Objective C itself, with Swift it's pretty much guaranteed they'll make significant syntax changes every major release (the last one in September did).
Developing a keyboard extension means sometimes your extension won't load for mysterious reasons, and you'll need to waste hours debugging why. My Swift keyboard extension is sometimes debugged solely with println() statements because I can't get the debugger to load. Since Apple's tools don't yet work well with Keyboard extensions, and also don't yet work well with Swift, using them together are multiplying your pain exponentially.
The end result is if you don't need to use this keyboard outside of your own application it's foolish to build it using the Keyboard extension API. If you do need to use the Keyboard extension API it's foolish to do it in Swift. This is written by a fool working full time trying to ship a Swift based keyboard extension.
If you want to use the standard cocoa custom input view API, then using Swift is probably fine. You will still have to deal with additional problems because it's such a young language, but you won't have lose so many days to mysterious, seemingly insoluble problems trying to figure out if they were caused by Swift, the Keyboard Extension API, failures in Xcode and it's debugger, or your own blunder.
I've read a lot of topics about developing a custom keyboard for iOS and it's clear that it is impossible to build a system-wide alternative keyboard.
But I still try to understand how Emoji keyboard(the emoticons additional layer) could make it possible and it is an official app on AppStore (that means it passes Apple approval!).
Note that their keyboard, once installed, can be added in Keyboard section in Settings!
Thanks for help
Emoji apps enable a by-default-disabled keyboard built into iOS. If I recall correctly, it's enabled by default in certain regions (Japan) but disabled in most places. So they aren't adding a new keyboard, just revealing one that's already there.
edit: ... and here's how they do it
The Emoji Icons are a stored in the private use area of unicode. They won't look any good on a different device than an iPhone/iPad, this is Apple specific.
The app is just to enable the keyboard. You can do it yourself: Making An Emoji Enabeling App.
Have a look at The truth about iPhone Emoji, which sheds some light on the whole topic.