(This question is mostly applicable to those of us developing iPhone apps without access to an iPhone 7.)
I want to incorporate the new taptic feedback available with the iPhone 7 into my apps, and I want to make sure my uses of it align properly with how iOS uses them at a system level. Without a device I can't test this.
Apple provides a document describing the different kinds of feedback: https://developer.apple.com/ios/human-interface-guidelines/interaction/feedback/ Namely "Notification", "Impact", or "Selection".
For instance, in Mail.app, when you slide a cell to archive it, it gives taptic feedback. Which of those three above (and their corresponding "variation") does Mail.app use? I'm guessing "Selection" but may be wrong.
Bonus points for pulling down Notification Center or Control Center, as well as any others you can provide for reference, but the gestures in Mail.app would be an awesome start.
You should check out this article, it gives you an overview how UIFeedbackGenerator works. https://www.hackingwithswift.com/example-code/uikit/how-to-generate-haptic-feedback-with-uifeedbackgenerator
Alternatively, you can create a demo project and check out which feedback is best suited for your needs.
Edit:
It's the selection feedback for Mail app. The notification center uses multiple feedbacks depending upon the sliding. If you do it slowly, it's impact heavy and how if you do it a bit slowly, it's impact light and if you just slide it down immediately, it produces no feedback.
Related
I've been using Apple's GameController framework so far, but there's no possibility to make the controller vibrate. I'm searching for something similar to Unity's Handheld.Vibrate(), but the last hours of research make me believe there's no simple API.
Is it somehow possible to make a Game Controller paired to macOS/iOS vibrate using Xcode? (Perhaps through directly sending signals to the controller)
Apple's response to my feature request via Feedback Assistant:
Thanks for your feedback! For now, this issue behaves as intended.
We love rumble in the Xbox Wireless Controller and Sony DualShock4 controllers, too - we think it would be great in games on iPhones, iPads, tvOS, and macOS, too.
Looks like this is finally possible! There’ll be a talk about this on Wednesday. I will update this answer as soon as it’s available.
According to Apple's Game Controller Programming Guide, this is not a supported way of interacting with controllers.
Understanding the Controllers Supported by Apple
Apple has created specifications for distinct kinds of MFi game
controllers.
Although specific controllers vary, many common characteristics must
be implemented strictly according to the specification.
The extended control layout contains the following controls:
Four analog face buttons arranged in a diamond on the right side of
the controller (labeled A, B, X, and Y)
An analog directional pad on
the left side of the controller
Two analog thumbsticks on the left and
right sides of the controller
Two analog shoulder buttons (labeled L1
and R1)
Two analog triggers (labeled L2 and R2)
A button to pause and
resume gameplay
The Siri Remote has its own micro control layout.
An analog directional pad on the top of the remote
Two digital buttons
(A,X)
One button to pause and resume gameplay
If you directly communicate with a given controller over Bluetooth or similar, you could directly issue controller-specific commands (such as vibrate). Obviously, this would be vastly more complex as you would essentially have to re-implement the GameController framework yourself, listening to commands in an event loop and responding to these in your app. Communication protocols to the controllers likely varies between different makes and models as well, adding even more complexity and cost to the development.
Your best bet is to submit a feature request directly to Apple, via Feedback Assistant.
It's coming to iOS 14 to support haptic feedback from the third party controllers. https://developer.apple.com/videos/play/wwdc2020/10614/
I am new to iOS development and wondering if it's possible to create a floating button which always stays on top of screen even if you have any other app running in full screen mode?
No you can't do that on iOS, Apple isn't allowing this kind of features (like Messenger on Android for example)
I assume you mean something closer to AssistiveTouch. When turned on in accessibility, it will stay on top of the screen, no matter what app you have open. I recommend reading the Apple Docs for further investigating into this, but at the moment, Apple does not let you do this. Your app can't mess with other apps. It's pretty against what Apple's design guidelines allow you to do.
Is there a work around for what you are trying to accomplish with this? Maybe if you expand your question, I can help.
Today, Apple announced to iOS7 developers:
Starting February 1, new apps and app updates submitted to the App
Store must be built with the latest version of Xcode 5 and must be
optimized for iOS 7. Learn more about preparing your apps by reviewing
the iOS Human Interface Guidelines.
http://techcrunch.com/2013/12/17/apple-requiring-all-app-submissions-to-be-optimized-for-ios-7-by-feb-1st/
What should we do about that? Use iOSSDK7.0 or later? Use Xcode5.0 or later?
Thanks
Optimizing for iOS 7 is not an entirely technical task. Yes, you should be using the latest SDKs and Xcode, but what this really means is that you should have read and following the iOS7 UI Transitions Guide, iOS Human Interface Guidelines and the various other style guides within the Apple Developer Center.
The requirements are :
Use XCode 5.0 or later
Use iOSSDK7.0 or later
Deference. The UI helps users understand and interact with the content, but never competes with it.
Clarity. Text is legible at every size, icons are precise and lucid, adornments are subtle and appropriate, and a sharpened focus on functionality motivates the design.
Depth. Visual layers and realistic motion impart vitality and heighten users’ delight and understanding.
Defer to Content - Take advantage of the whole screen, Reconsider visual indicators of physicality and realism, Let translucent UI elements hint at the content behind them,
Provide Clarity - Use plenty of negative space, Let color simplify the UI, Ensure legibility by using the system fonts, Embrace borderless buttons
Use Depth to Communicate
Just look at original Apple apps, your must follow that style
Addition info at links
https://developer.apple.com/library/ios/documentation/userexperience/conceptual/mobilehig/Anatomy.html#//apple_ref/doc/uid/TP40006556-CH24-SW1
https://developer.apple.com/library/ios/documentation/userexperience/conceptual/mobilehig/index.html
I want to design a page with tab bar on top of it.In some articles of this site.(i missed urls) i found that this is not a common way and the question gets some down rate.
The question is this: whethere having a design like this may cause that apple not approve the application on his store?
Even if it doesn't make Apple reject your app, think of the users not being used to the tab bar being at the top and how that is going to affect how well the app does in the Store.
Every platform has its own design patterns and there is a reason for that. If you stick to them there is a higher chance that the first-time users have an easier time using your app, which results in a higher chance that they keep using it. If they don't know how to use it or find it hard, they will move to another one.
Take a look at the Human Interface Guidelines and apply them. It will do good.
What commonly expected user-visible design idioms need to change from an iPad app to a Mac app for an app, that is to provide basically identical functionality, to seem at least reasonably Mac OS X native?
Some of these changes, commonly expected by users, might include:
Move the Settings button and Info button to Menu selections for Preferences... and About...
Move the Settings view and Info view or popover to their own independent Preferences and About windows instead of being views in the main window.
Add some menu items and menu keys for commonly used buttons (like the forward and back buttons in a browser).
Support arrow keys for scrolling any custom view items.
Support mouse-over for help popups or dynamic menus.
If the app supports "documents", allow more than one document to be open at a time, each in their own windows.
What else? What's the minimum change required for a simple generic 2D game?
Added clarifications:
Note that I do not consider re-coding similar UI classes to NS classes (for instance UIButtons to NSButtons), with similar look, positions and behaviors, to be a significant change. Those changes are pretty much invisible to the user.
The goal is to change as little as possible so that a user who purchased app X to do Y on an iPad might purchase app X to do Y on their Mac, as a Mac application, but with as close to zero learning curve as possible. But it seems that some changes need to be made, or the app would not seem to be a Mac app (for instance, a missing About... menu item would seem a bit strange.)
to provide basically identical
functionality, to seem at least
reasonably Mac OS X native?
You've gone off the rails right there. Consider adding this to your list:
Forget everything you know about how your iPad app works. Step back and consider that a user's interaction with and expectation of a desktop application are very different from those of a tablet. Re-think what you're able to do and what the user will want to do with a faster processor, more power, significantly more available storage, less mobility, much faster text entry, and a different user interface model.
We are in the same boat and faced the same question.
Our conclusion is to start with a "fresh" real application for Mac and make it look similar, i.e. using the same or similar UI components and graphics. The app should be otherwise developed as if there was no iPad version.
First, there will be many users that don't have the iPad version. Those users expect a full-blown Mac application and it doesn't make sense to make it feel iPad in any way.
Second, users coming from the iPad version will feel ripped of if the Mac app is just a pure clone of the iPad version with no added value. Think of the first transitions from iPhone to iPad - paying again for nothing but pure upscales is frustrating and might harm your business in the long run.
Starting out designing a fresh streamlined UI and then think of what you can reuse and make similar. Functionality may differ in one direction or the other. Your model code should work in all places anyway.
Not exactly an answer to your question, but take a look at Chameleon. It's essentially a port of UIKit to the Mac. It was created by The Icon Factory to make it easy for developers to port their iOS apps to the Mac. IIRC Twitterific was ported to the Mac using Chameleon.
So here's what I did to create a Mac app from an iPad app, and have it accepted into the Mac App store.
Ignored the suggestions to completely redesign the app (users reasonably liked the iPad design).
Create a Mac app project and include a branch of all the iOS source code.
Manually recode all the UI elements with their corresponding NS elements. Resize them to Mac UI guideline sizes. Check that they all show up in some reasonable place when the main window is resized. Deleted iPad only delegates, such as rotation handlers, etc. This resulted in completely new view controller code, but almost all the code was just a parallel translation of the other paradigm.
Set the view coordinates to flipped so the Y coordinates won't have to be recalculated for any Core Graphics drawing routines. (The Model and CG drawing code pretty much ported straight over without change, except for scale factors for window size, and such.)
Remove settings and help views from the main window view controller(s). Implement a Preferences window xib and a Help window xib, and put all the settings and pref views and controls there. Add one more top level controller to show/hide the 3 windows.
Add some menu selections with hotkeys for equivalent UIButton actions that a user might want to hit without reaching for the mouse/trackpad.
Add a credits.html file.
Add an outline shape and transparency masks to the icon design, and stuff into an .icns file.
Pad the one window screen shot out to the much larger required size.