I want to design a password screen for my Apple Watch app. UITextField is not supported by WKInterface. How do I design such a screen? Are any APIs or customizations available?
There really isn't a good way to input a password from apple watch. Apple doesn't want you to do this, so even if you find a way to do it, I would bet apple would reject your app. Also take into account that the apple watch locks every time it is removed from your wrist, so you have to type in a password to use your application anyway. However, if you still want to input a password from apple watch, I would suggest building it yourself. Just use the digital crown to flip through the alphabet and add the character to a password string once the user taps it.
You can try to build a calculator like keyboard with groups and buttons.
The closest equivalent to iOS's UITextField is the text input method presented in WatchKit using presentTextInputControllerWithSuggestions:allowedInputMode:completion:
This would seem like a pretty poor way to input a traditional password, given the vagaries of dictation, though you could think about this more flexibly. For instance, what if the required 'password' was to dictate a phrase that included at least three words out of four words that had been pre-set as the passphrase. That would have a fair degree of entropy, but account reasonably for the likelihood that at times one of the dictated words might be mis-recognised by the API.
Related
I'm creating a settings bundle for my app to allow users to set their default application server. How should I be validating the user input for a Text Field in the settings?
I've found this post from 6 years ago, and also have read through the apple docs and realize there is no mention of input validation.
There is no way to do input validation for stuff in settings.bundle while the user is typing. You'll need to do this when your app starts, and/or in response to the UserDefaults.didChangeNotification notification, and there's no really good way to provide user feedback.
That said, there are 3rd party libraries out there that allow you to move this stuff from the system's settings app into your app directly, making it much more easy to access, and also allow a high degree of customisation, in particular https://github.com/futuretap/InAppSettingsKit.
I've been developing iOS apps for enterprise use for several years now. It was an adjustment from having spent many (!) years developing desktop apps. One of the first things I learned very early on was that it is frowned upon for an app to kill itself. The posters in the Apple dev forum were downright hostile about it, which is a reason I never go there anymore.
Now I have an app that has very critical functions, and it requires that the user accept the terms and conditions before using the app, and that the app will not function if the terms have not been accepted. The choice is there to accept or to decline, but it seems like the best thing to do when the user actively declines is to kill the app entirely.
My question is, under those circumstances, would there be anything wrong with that? Will I be damned to developers hell for eternity?
You can change the interaction here.
Instead of accept (and use the app) or decline (and never be able to use the app) change it to accept (and use the app) or nothing.
If the user does not accept then they cannot use the app. They do not have to decline anything. Absence of acceptance is all you need.
If they don't accept then don't do anything. They can always come back later and accept and start using the app.
Why kill an app on a declying? I would rather just leave a user at the same screen with no actions before he puts acceptance checkbox, disabling all buttons
If you make the app kill itself, Apple won't let you post it on the App Store.
You should adjust your User Experience to the case of the user declining the terms and conditions.
For example, show a screen saying that the app can't be used unless terms are accepted, with a button saying "Take me back" that takes the user back to the terms screen.
I had made a custom sticker keyboard. Basically users touches one of the gif images that I have placed on the keyboard, i do a a copy action on that image and then the user pastes it to iMessages. For this to work i need to have user do "Allow Full Access". Without it the copy action doesn't work. Now, my app got rejected with this message
From Apple
25.5 - Keyboard extensions must remain functional with no network access or they will be rejected
25.5 Details We noticed that your keyboard extension does not function when the “Full Access” setting is toggled off.
Is there anything i need to set in my info.plist file? Did the reviewer didn't understand how my app works i.e. need to do rejection appeal or do I need to do something else? Trust me i googled but didn't find much on this topic
Here's the answer to my question that eventually led to my app approval.
It doesn't matter if your app is custom sticker keyboard only. It "must" have "both" alphabet and numeric keyboards. If it doesn't then it will be rejected.
From Apple Review Guidelines
4.4.1 Keyboard extensions have some additional rules.
They must:
Provide keyboard input functionality (e.g. typed characters);
Provide
a method for progressing to the next keyboard;
Remain functional
without full network access;
Provide Number and Decimal keyboard
types as described in the App Extension Programming Guide;
I am trying to get some input from the user on the Apple Watch using presentTextInputControllerWithSuggestions. I wonder what happens if user speaks multiple languages – is there a way to detect which language has he spoken?
Also, is there a way to find out what languages are set in his preferences?
Not having a Watch on hand, I don't think anyone here knows. (Edit: this was first posted before the Watch launched.) But even though it'd be really cool if there were dictation software that could guess cual idioma で話しています from word to word, watchOS is no different than iOS in that respect.
In iOS, Siri listens only in the language you set in Settings, and dictation listens only in the language of the active keyboard (whose microphone button you pressed to start dictation).
In watchOS, Siri likewise has a set language. Dictation is based on the keyboard language last used on your paired phone, but you can also change the language during text entry with a force press. That's a user choice for a system service, so it's opaque to the app, just like choice of keyboard is to an iOS app. (You're welcome to perform some sort of text analysis of you want to know what language of text the user has entered.)
In an iPhone app I want the user to do some input in a different language.
For example the user is an English speaker and has his(or her) device set with the English language. When running my app he(or she) will have to input some French and some Japanese.
Is there a way I can bring the proper keyboard from inside the app without forcing the user to change his(or her) usual settings. According to what I have read up to now, I am not sure there is a good answer. I still hope.
Thanks for any tip.
You can usually pick certain keyboards (numeric, email, etc) from the interface-builder-like aspects of UITextFields, so take a peek at the code options for setting those things. You may be able to pick it that way.