I've been reading the App Store Review Guidelines (including linked websites in) trying to find if there are some restrictions about the fonts that are used in the app. I'm doing an app which needs to look modern and the typography is a very important thing to make look it. I haven't found any related topics on the official documentation, but i'm not sure they will pass the review. Right now i'm using Roboto font (from Android, yes) because it looks very great but the fact that it's an Android font could bring problems on the approving process. Does anyone had this situation or knows what happened in that case? Is there any restriction about the typography used in the apps? So many thanks!
As long as you have a license ("the rights") to use the font as you are, Apple doesn't care.
App Store Review Guidelines 8.5:
Apps may not use protected third party material such as trademarks, copyrights, patents or violate 3rd party terms of use. Authorization to use such material must be provided upon request.
The license for Roboto is the Apache 2 license, available at http://www.fontsquirrel.com/license/roboto
The main thing to do is not strictly for app store approval (though it may help with human interface guidelines compliance) but for unifying aesthetics. Make sure that there really is a need to use a custom font. iOS includes quite a few fonts: http://iosfonts.com and whenever possible it's always good to use the built in components.
Related
My App uses a custom ancient font for a language that is about to be extinct, interesting right.
Now I am using the custom font thru out my app but I need to install the font into the iOS operating system I hope this is possible so that I can copy and paste text from my app into other apps like email, SMS and especially Facebook otherwise the chars come up as squares because Apple don't even support their unicode.
I think its possible because AnyFont is an app that does that without jailbreaking.
This feature is a crucial feature for users using the app to be able to communicate with the language.
So this would be much appreciated if someone could help me with some hints please.
I am not sure if I need to post code here !.
Thank you,
Kind Regards,
Will
You have to create a configuration profile for each font. With the manual installation by the user of that profile the font will be available for Numbers, Keynote and some others. It's available since iOS 7.
See Apple's reference page for that. Basically, you have to use the Font Payload:
A Font payload lets you add an additional font to an iOS device. Font
payloads are designated by specifying com.apple.font as the
PayloadType value. You can include multiple Font payloads, as needed.
...
Each payload must contain exactly one font file in TrueType (.ttf)
or OpenType (.otf) format. Collection formats (.ttc or .otc) are not
supported.
You can also take a look at here:
http://www.saturngod.net/create-custom-font-for-ios-7
If you're using a Mac, you can also checkout Apple's Apple Configurator which allows you to create those MDM profiles too.
Is it possible to build assistive applications for the iPhone that work in the same manner that VoiceOver does? (Using the UIAccessibility API) - To clarify, We would like to build a screen reader in the same vein as VoiceOver. Or, is VoiceOver the only assistive technology that is allowed to work on an iOS device?
Yes, you could build your own screen reader technology into your own app.
You would have include your own speech synthesis library, such as CMU FLite, which may not sound as good as VoiceOver, and subclass or add categories to all of your app's UI and text objects that you wanted to support your private assistive behavior.
There are a small number of talking apps in the iOS App store that do some limited custom voice assistance within some of the app's views, without VoiceOver having to be on. (Advertisement: my Talking Tuner is one example.)
Your assistive tech would only work within your own app, and would not be able to interact with the physical button or any other apps as Siri and VoiceOver can.
VoiceOver is currently the only assistive technology app on iOS, and I suspect that Apple will keep it that way. There's a bunch of benefits to having the screenreader being part and parcel of the whole package rather than allowing 3rd party apps, including:
A screenreader, by definition, needs to be able to access the UI and contents of other apps. There's a whole bunch of security and privacy issues here. While there are some ways to mitigate this - eg. Android requires assistive technologies to be specifically given permission in a control panel - why even go there if it's not needed?
Some of the things that VoiceOver does - like intercepting touch - likely need special system support; and again that's not something that you generally want to allow any app to do. There's a sense in which a screenreader is a special case of app, and it's far easier to manage these cases where a screenreader needs special support from the OS if its all in-house than if that support needs to be extended to 3rd parties via some API, and that API needs to be somehow secured against misuse (see point above), and the API has to be documented and supported in future OS releases.
Having one screenreader means there's just one app to test with for accessibility. This hugely simplifies life for the developer. On iOS, test with VoiceOver, and you're done. By contrast, on Windows, you have to test against perhaps JAWS, NVDA, and maybe WindowsEyes too. And some of these apps do things that others don't, so your app may need to workaround one or the other.
Having the screenreader being part of the package also means that it works with new features right from OS release. Apple can guarantee that new iOS features are accessible from day 1. To do this with 3rd party accessibility software, they'd have to let 3rd parties in on new OS features, which is unlikely for a company as secretive as Apple.
Unfortunately, VoiceOver is currently the only assistive technology allowed. If you need to work with VoiceOver, it is pretty easy; all you have to do is add this line of code for each items you want the user to identify:
[myView setIsAccessibilityElement:YES];
[myView setAccessibilityTraits:UIAccessibilityTraitImage];
[myView setAccessibilityLabel:NSLocalizedString(#"Image of dog", nil)];
Is it possible to make iOS and Android apps compliant with Section 508 of the U.S. Rehabilitation Act? I have an upcoming meeting where this question will be raised.
See here for Apple's docs on how to make apps fully accessible: Accessibility Programming Guide for iOS
In particular:
If you use only standard UIKit controls, you probably don’t have to do much additional work to make sure your application is accessible. In this case, your next step is to ensure that the default attribute information supplied by these controls makes sense in your application
I've done a couple of section 508 reviews but don't take what I say as the final word or a legal opinion.
Section 508 is usually used in government contracts and is part of the purchasing process. If your app is not completely 508 compliant this won't mean you can't get the contract, it just means you may lose out if someone has an app that is more compliant then yours with the same general feature set and usability.
As far as 508 compliance on a mobile device the VPAT, which is the form you need to fill out does not specifically mention smart phones. Take a look at
http://www.itic.org/policy/accessibility
To view the current VPAT. If I had to fill out a VPAT I would focus on "Section 1194.21 Software Applications and Operating Systems" since you are writing an application for what is basically a computer with assistive technology on it.
I'm a totally blind iPhone user and from my personal experience with the accessibility of Apple's built in applications as well as many third party applications I would say creating an application that is 508 compliant or very close is doable.
Android is a different story. I don't have any firsthand experience with Android but do to the different levels of Android, different hardware, and customizations from the device makers that may negatively impact accessibility you can't guarantee your app will be accessible. The best you can do is try to find a handset with good accessibility, develop on that handset, and in the VPAT make it clear that you only tested with one specific hardware device so your results will vary. With Apple it's safe to say that if an app is accessible on iOS 4.0 it will be accessible on an iPhone 3GS, iPhone 4, iPad, and iPod touch since they control the operating system and hardware. My understanding is that Android's accessibility API is more limited then Apples so that is something else to take into account.
For an introduction to making iPhone apps accessible other then Apple’s documentation see this
For an introduction to general Android accessibility see this. Pay attention to the choosing a phone section for more detail on the fragmentation issue I mentioned earlier.
For a developer introduction to writing accessible Android apps see this
Sure, you can use a similar feature to VoiceOver, vibrations, sounds, use the flash on the iPhone 4, etc. You can't use braille though.
this is my question...
I have a compilation(UITableView) of videos from youtube of a particular genre (funny videos, for example) and I want to know if this app will pass the approval process.
These videos are freely accessible by anyone in youtube, but isn't uploaded/recorded by me.
This is a concept:
http://img263.imageshack.us/img263/3466/img0075.png
(obviously with a cool skin design and more options like Favorites, Share with friends, etc)
Thanks for reading.
If everything you can do with this app is possible (easily) with the Youtube app that Apple ships, it will probably not be approved. The app has to add some value. Apple has disapproved apps that copied apps that shipped with iOS before. If your app adds something it will probably be approved.
You will be breaching several license terms by doing that, not only Apple's but also YouTube's:
Excerpt from YouTube license terms, paragraph 5:
Your Use of Content on the Site In addition to the general restrictions
above, the following restrictions and
conditions apply specifically to your
use of content on the YouTube Website.
...
B: You may access User Submissions for
your information and personal use solely as intended through the
provided functionality of the YouTube
Website. You shall not copy or
download any User Submission unless
you see a “download” or similar link
displayed by YouTube on the YouTube
Website for that User Submission.
...
E: You agree to not engage in the use,
copying, or distribution of any of the
Content other than expressly permitted
herein, including any use, copying, or
distribution of User Submissions of
third parties obtained through the
Website for any commercial purposes.
There are probably other terms from YouTube that prevents you from distributing these movies though you own application. But just one of those caluses prevents you from distributin it though AppStore as detailed in Apple's terms:
5.1 You represent and warrant that: (a) You have the right to enter into
this Agreement, to reproduce and
distribute each of the Licensed
Applications, and to authorize Apple
to permit end-users to download and
use each of the Licensed Applications
through one or more App Stores; (b)
none of the Licensed Applications, or
Apple’s or end-users’ permitted uses
of those Licensed Applications,
violate or infringe any patent,
copyright, trademark, trade secret or
other intellectual property or
contractual rights of any other
person, firm, corporation or other
entity;
...
So the answer in short is no.
I am not sure but I see no reason that Apple will reject this app
Apple doesn't want anyone to create iPhone apps outside of the Xcode/Objective-C environment. How can they actually enforce this?
If the non Xcode IDE, for example Unity, compiles to an iPhone executable, how will Apple know which dev environment you used to create the app? Can they have Xcode compile some sort of signature into the executable that no one knows about?
For tools such as unity, corona, flash, and other platforms used to 'generate' iphone apps, Apple may be able to 'decompile' and examine your app (look at patterns of generated functions, etc). From this, they might be able to guess that your app was generated with such a tool.
In the limit, this is impossible. Consider the following: I write some script code to generate a bunch of objective-c code. Then I manually import the objective-c files into xcode and build the app. How would apple be able to distinguish the script-generated code from human-written code? Maybe I just tend to write code that happens to look machine-generated. There's no way for apple to determine whether the code was "originally written in objective-c, c, c++ or javascript" or not, yet this would still, technically, violate the agreement. That's why the 3.3.1 part of the agreement is nonsense.
Most automated systems do things a particular way, which isn't hard to detect. If you've ever looked at the PHP or JavaScript code Adobe Dreamweaver generates, for example, you know how easy it is to find stuff like this.
Apple is doing this to prevent people from using Adobe's Flash development framework. It should also be noted that Apple's decision to limit Application Frameworks like this is causing the DOJ/FTC or some government agency to start an informal inquiry into monopolistic practices.
From this article:
"According to the Post's Hollywood source, Apple's ban of Adobe's Flash technology on the iPhone and iPad is what prompted the government to poke around. "
They really don't have an issue up until now with other frameworks because Adobe didn't have one based with the Flash environment. Now that there is one, Apple is going to restrict anything that talks/looks/smells/acts like an Adobe Flash app on the iPhone. In my opinion, they won't do anything to other frameworks, but they'll enforce the rule just for Adobe. Which brings up the whole monopolistic practices thing.
I believe that many of these translator tools have some kind of common runtime function library which take care of the portions that could not be translated 1:1. Those function could then be pretty constant regardless of your application. That way there would be no real need to decompile the app. but instead just look for usage of those function signatures.
FWIW I find the whole idea of limiting user's choice of tools is a bad move.