After reading through the extensive App Store guidelines (mac app store specifically), I've noticed a contradiction....
On one hand, under functionality, it clearly states:
2.7 Apps that download code in any way or form will be rejected
2.8 Apps that install or launch other executable code will be rejected
Yet when you read up further about purchase types, it often refers to in App Purchase 'downloads' and I'm pretty sure I remember reading in the bundle development guide (specifically plugin development) that these could be considered as in app purchases?
in 2.7 and 2.8 above, do they refer to code that they haven't checked i.e myAppPurchase.bundle which wasn't submitted at the app submission time, or is this concrete that absolutely NO bundles checked or unchecked by apple can be downloaded at all?
So in short, should an app be created in it's entirety i.e. with all the 'in app purchase extras' or can it be done modular i.e. an in app purchase downloads an approved bundle from the app store?
Cheers,
A
Although you can download content for in-app purchase, you aren't allowed to download code for later incorporation into the application. There are some theoretical edge cases, as you might have your own interpreter and might be able to download some amount of interpretable code in that case, you cannot download native code which will be executed either as part of the application (plugin) or an externally launched application.
As for the question of why Apple would cover this in the docs, it's likely because its the way that OS X and iOS apps are stored in the file system. Until Apple decides to allow downloadable binary executables, we're stuck using Plugin bundles in OS X only, ditto for non-OS framework bundles, which would arguably be even more useful. In particular, we have some bundles that are iOS/OSX cross-platform that we have to statically link under iOS, which is a shame.
Apple's apparent take is that if we can load code dynamically, then it is an opportunity to circumvent their review process by downloading an offending code module after the initial (or subsequent) program load. Imagine, for example, an application that talks to a server to download code which violates one of Apple's guidelines. If the version that is making the request has not yet been "released" by the malicious developer, no code is returned, and it just looks like it's checking in for an informative message of some kind. However, once Apple approves the App, the developer tells the server to start sending back a dynamic library, framework, or plugin which is then executed at the appropriate time by the now-malicious code.
The difficulty is that to prevent this from happening (through dyld or similar), you need to either whitelist everything that can be loaded, or you need to just prevent its use by application code altogether.
There's certainly the possibility that some kind of approved code whitelist could be used in the future, but until then, Apple has apparently chosen the route of just preventing the use of dynamic linking of non-system frameworks.
Related
I submit the APP has been rejected several times to Mac AppStore. it is a video application which base on VLCKit, only used the third-party library also is VLCKit. here is the app rejection issue :
"Performance - 2.5.1
Your app uses or references the following non-public API(s):
'/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices'
: CGSCreateRegisteredCursorImage
The use of non-public APIs is not permitted on the App Store as it can
lead to a poor user experience should these APIs change.
Next Steps
If you have defined methods in your source code with the same names as
the above-mentioned APIs, we suggest altering your method names so
that they no longer collide with Apple's private APIs to avoid your
application being flagged in future submissions.
Additionally, one or more of the above-mentioned APIs may reside in a
library included with your application. If you do not have access to
the library's source, you may be able to search the compiled binary
using "strings" or "otool" command line tools. The "strings" tool can
output a list of the methods that the library calls and "otool -ov"
will output the Objective-C class structures and their defined
methods. These techniques can help you narrow down where the
problematic code resides.
If you are unable to reproduce this issue, ensure you are testing the
exact version of the app that you submitted for review, and that
you're doing so in a minimally privileged environment. See Technical
Q&A QA1778: How to reproduce bugs reported against Mac App Store
submissions.
For information on how to symbolicate and read a crash log, please see
Technical Note TN2123 - CrashReporter."
That made me crazy , according Apple's feedback, I have used "strings","otool -L" and "otool -ov" , but didn't find relevant content. how to solve this problem? please tell me.thanks!
VLC calls CGSCreateRegisteredCursorImage() in code used for screen capture.
You will probably need to remove this functionality from libvlc to make it pass App Store API checks.
More importantly, though, VLC (and libvlc) are licensed under the GPL. Please make sure your application will be compliant with this license before you proceed.
I am quite confused as to the proper way of distributing Bonjour as a part of a Windows application that would publish a service for a client iOS app.
No matter how much I google around, I cannot find a clear how-to guide. It would be great if someone could provide guidelines.
The main reasons of my confusion are:
Is it mandatory to distribute the entire bonjour Win SDK as a part of my Win application?
Since Apple provides source code to build mDNSResponder.exe, is it sufficient to only distribute such file along with dns-sd.dll?
What is the intended purpose of providing sources for mDNSResponder.exe otherwise?
What is the recommended way to handle the possibility of having Bonjour already installed on the system?
Also, where can I find the latest Bonjour SDK (3.x I guess?), I can only find 2.0.4. Is it only accessible if I am enrolled in the OSX developer program? (I am enrolled in iOS developer program for now.)
Many thanks.
This is information I gathered from various sources, including communications with official Apple support. I report it in the way I believe to be accurate, I hope it can be useful (no liability assumed!).
For Bonjour-enabled Windows application you have basically two main options:
Bundle the Bonjour Installer with your application (which is not the Bonjour SDK, the SDK if for your own developer use only).
If you choose to do so, the Bonjour installer must be called from your own installer during the installation process. The possibility of Bonjour being already installed in the system is totally handled by the Bonjour installer.
And here come some bad news: you must include de Bonjour Logo on your physical distribution medium (like a DVD cover sleeve) according to the Apple guidelines specified in the Windows Bundling Agreement, and you need Apple approval before distributing your product.
Do not bundle. I.e., do not distribute Bonjour with your application but simply use it if already present in the system. If you do not distribute Bonjour in any form the whole Windows Bundling Agreement simply does not apply. You application should search for the dnssd.dll and load it dynamically if found.
Consider that most of Windows users would have Bonjour already installed due to the fact that some popular apps use it (for example iTunes and Skype).
While the source code of Bonjour is released under an open-source library (Apache License, Version 2.0) this does not require Apple to do anything. In particular, they do not need to document how you'd use this license.
The license allows you to use and adapt Apple's source code, including its copyright, but not including its trademark "Bonjour(TM)". Since this is the standard Apache license, you don't have the requirement either to show the trademark.
So, to answer your questions:
No, you can build your own version of Bonjour from source and use that under the Apache license. You can't call it Bonjour, but why do you need a name in the first place? "mDNS" would be a reasonable choice, possibly prefixed with your trademark.
It seems sufficient to distribute the DLL and EXE. Arranging how they find each other might benefit from some tailoring, so your own build of Bonjour doesn't clash with Apple's.
(I won't speculate on Apple's motives)
The design problem here is that Bonjour acts as a system service, and services are inherently singletons. If you install it unmodified, Apple wouldn't be able to install its own build. That's not a legal problem, probably, but it is a bad customer experience. Installing your own build as a distinct service would avoid the clash, allowing both versions to co-exist.
(Resource request, off-topic)
I'm trying to write a plugin for Office on Mac to match some functionality I have on Windows. I've been working with Word 2011 for Mac to create a PoC. I can get my library loaded into Word in various ways, but I'd really like something clean and (at least somewhat) supported.
I've discovered a WordPDE.plugin inside the app bundle, but DYLD_PRINT_LIBRARIES reveals that the plugin is never loaded under typical operation (Start app, create doc, type content, save doc, quit app.) I placed a dummy plugin beside WordPDE.plugin only to have it ignored by Word.
I also see that the Office apps include a MicrosoftComponentPlugin.framework but the information reported by class-dump doesn't help determine how to write a "Microsoft Component Plugin" nor how it might actually get loaded.
Ultimately, I can get my library into Word by asking dyld to do it, or by modifying load commands in the executable, but I'd much prefer going a cleaner route with some kind of plugin. Is there anyone with any information about how Word for Mac loads and uses this plugin and/or the mentioned framework?
I work on a vertical-market Mac application that uses a USB dongle to make sure users have paid for it. It's expensive enough, and in enough demand, that "black hats" have tried to crack the dongle scheme, so the app checks the executable and key resource files at runtime, and if something has been tampered with, the program won't run.
With PKI (Public Key Infrastructure) based code signing becoming more commonplace in the Mac world, I'm considering switching to using it to do this runtime verification, which would have the nice side effect of making Gatekeeper happy.
However, Apple's interest is very different from mine. Their focus is on making the user happy, so if an app has an incorrect signature, Mac OS X will simply ask the user if they want to run it anyway. My focus is on thwarting crackers, so if my app has an incorrect signature, I simply don't want it to do anything that's useful to an end-user.
So I want my app to be able to validate its own executable and resources, using Apple's signatures, at runtime.
Also, from what I've read of the libraries offered Mac OS X for doing validation, they simply give a "yes" or "no" answer to requests to validate an executable. It strikes me that this is susceptible to "black hat" attack in a number of ways - for instance, one could simply replace Apple's tools with ones that always say, "yes, this is valid", either in the system directories or by changing the search path for those tools. So I think it might be a good idea to build the complete set of signature validation code into my app.
So I have a few questions:
What PKI libraries/APIs are available to let an app validate its own executable and resources which have been signed using Apple's codesign system?
Do these libraries have source code available?
Are my security concerns about using the PKI libraries Apple ships with Mac OS X valid, or are they safer to use than I think?
Does anybody have experience with this kind of thing they'd be willing to share? Are there other gotchas or tips?
Thanks in advance for any help with this.
To answer #1 and #2 above, Apple has open-sourced its code for creating and verifying digital signatures as libsecurity_codesigning. So a developer could build that into their app to let it validate its own signature.
Alternatively, MacOS's version of this library can be used by an app - but the API is private, so that's a gotcha. There's a brief discussion at this link.
Does Mac App Store accept application written in Python/Java/Ruby?
The Good News
Yes, you can submit a Java app to the Mac App Store. Not true in the past, but it is true at least as of now in 2013.
One example is the successful MoneyDance personal finance app currently available for sale in the Mac App Store.
The Bad News
Preparing and submitting your app is neither simple nor easy. You have to jump through some hoops.
Your app cannot depend on Java being installed on the Mac. You must include a JRE (Java Runtime Environment) within your Mac app.
You must write a thin Objective-C wrapper around your Java app. The source code and examples/tutorials are available on the web.
Like any other app, you must go through all hassle of the complicated build and deployment rigmarole with security restrictions Apple requires of any Mac App Store app.
More Info
Two articles, Take your Java application to the Mac App Store and Forking the OpenJDK for fun and profit, by Marco Dinacci. These articles may provide other useful information, but fortunately their discussion of forking the JDK is now outmoded. He and others have provided the needed patches now incorporated in the official releases.
How to Create a Mac OS X Installer for a Java Application (Updated for Mac OS X 10.8 — Mountain Lion) by Dem Pilafian of Center Key Software.
Packaging a Java App for Distribution on a Mac (Oracle)
Submitting to the Mac App Store (Apple)
By the way, you can use both Swing and JavaFX in your app. JavaFX is now bundled with Java, at least as of Java 7 Update 40 according to these Release Notes.
Java 9
The newly released Java 9 should make this process of wrapping an app with a runtime even easier and better.
Modules
Java 9 brings “modularization”, Java Platform Module System (JPMS), where the approximately 5,000 classes bundled with a JVM are grouped into about a hundred chunks known as modules. You can include only the modules containing classes actually used by your particular app rather hauling along every library. If you don't use JSON or CORBA, then you need not include the JSON or CORBA related modules.
The new jlink tool does this work for you, to assemble and optimize a set of modules and their dependencies into a custom run-time image. As a bonus, some link-time optimization work is performed to make your app launch faster.
These features are supported on 64-bit macOS systems, along with other platforms.
Native compiling
Java 9 also brings new support for native compiling, to build an app optimized for specific hardware. But this ability is experimental, and not yet ready for production use.
Update, as of 2018
Oracle has announced the end of web deployment technology, including Java Web Start, the previously recommended avenue for desktop apps. So now, Oracle expects all Java apps to be delivered bundled with a JVM such as is done with the jlink tool mentioned above.
So, the process of wrapping an app with a Java runtime that was something of a rarity just for the Apple App Store is now mainstream. Oracle expects any Java-based desktop app to be installed this way.
Yes and no. Apple doesn't care what language your App is written in, but it cannot depend on or install anything outside of the binary you submit to Apple. The relevant guidelines are below:
2.14
Apps must be packaged and submitted using Apple's packaging technologies included in Xcode - no third party installers allowed
2.15
Apps must be self-contained, single application installation bundles, and cannot install code or resources in shared locations
2.16
Apps that download or install additional code or resources to add functionality or change their primary purpose will be rejected
So, while this means you can't depend on Ruby or Python, you could use a framework like MacRuby to build your app in Ruby and embed the Ruby interpreter. Speaking for MacRuby, apps have been successfully submitted to the Mac App Store this way.
Ruby ? Yes !
Apple already accepted one of my apps written in MacRuby.
AFAIK, Cocoa will allow you include code written in different languages (including Ruby and Python, but not Java I don't think).
Check the Apple SDK's for more info, but I believe (thanks to Cocoa) it's not a problem.
For Python apps, I wrote a comprehensive article explaining how to build and submit such apps to the Mac App Store. It includes source code and build scripts for a barebones example app that I have successfully submitted.
Submitting a Python App to the Mac App Store
Possibly Java, if you bundle the Java application into a mac application.