4 Performance: Hardware Compatibility
Performance - 2.4.5
Your app uses still one or more entitlements which do not have matching functionality within the app. Apps should have only the minimum set of entitlements necessary for the app to function properly. Please remove all entitlements that are not needed by your app and submit an updated binary for review, including the following:
com.apple.security.files.downloads.read-write
It is not appropriate to predetermine the path that the user may have their files located.
Apple has indicated it is not in their judgement that your application requires reading or writing in the Downloads folder without user specification.
Disabling the com.apple.security.files.downloads.read-write will still allow users to save and open files located in their Downloads folder through standard interfaces (NSOpenPanel, NSSavePanel).
Note that it will disable your application from saving and opening arbitrary files in the Downloads folder without first being selected by the user.
Related
I have a WPF app that I am planning on deploying with the Windows Application Packaging Project in Visual Studio that makes the MSIX bundle for installations and future updates. The installer automatically installs the app in C:\Program Files\WindowsApps. This is fine until the program needs to cache some data or it needs to modify the appsettings file since the app does not have permission to get to these resources.
Is there a setting I can change in the packaging properties/manifest so it can install somewhere else so I can avoid these problems?
Indeed, only the Windows can write in %ProgramFiles%\WindowsApps when installing the msix package (by design). If your app is writing log files or other data inside the installation folder it will crash.
You need to either update your code to write to %AppData% or, if you don’t have access to the code, use the Package Support Framework to fix it. You can read more about here:
Package Support Framework (aka PSF)
The PSF brings support for API redirection and hooking. Thus, you can fix an app that failed to write a file in the installation folder (this is no longer allowed) and redirects it to a recommended location, or maybe simply update the app’s working directory.
As mentioned above, you cannot write in the install location of an MSIX package - this is by design.
For apps that are no longer under active developer indeed using the Packafe Support Framework is the only way to fix them. However, from what I see you are preparing to launch the app, so you have access to its code.
In this scenario, it is recommended you save all your app settings in the AppData\Roaming folder. For apps deployed as MSIX Windows will automatically redirect it under the Packages folder, but that is handled automatically by the OS, so you don't need to worry about it. More details below.
How to save data under AppData\Roaming instead of AppData\Local\Packages
I have an existing OSX app that supports OSX 10.5 onwards. I want to publish it to the AppStore and therefore I need to sandbox the app. I guess sandbox app should be supporing 10.7 onwards.
The app uses a folder in the username directory to create temp files etc
It also copies a sql db file which already has empty tables to the same temp folder and upates records as the app is used.
Furthermore if there is a crash it picks up logs from the crashlog folder of osx and requests user to submit them to developer.
Question
with a sanbox app, where do I store temp files ?
Where should I place the db file which can be read/witten to + new App update should be able to find exsting db file.
Should the custom code for crash reporter be kept or be made redundant ?
Thanks
where do I store temp files ?
In the directory recommended by NSTemporaryDirectory(). (This applies to both sandboxed and non-sandboxed applications.)
Where should I place the db file which can be read/witten to
In your application's Application Support directory. Use NSSearchPathForDirectoriesInDomains() to find it, then append your application's name. Again, this is the same whether you're sandboxed or not.
new App update should be able to find exsting db file.
Not possible. You can ask the user to locate the existing file with a NSOpenPanel, but you can't open it yourself, because it'd be outside your sandbox.
Should the custom code for crash reporter be kept or be made redundant ?
You'll need to remove it, because it won't work under sandboxing — crash reports are not stored to your sandbox. You will receive crash reports for your application through iTunes Connect.
Alternatively, you may want to look into a third-party crash reporting service like PLCrashReporter.
There is a mechanism to migrate the data of an existing App into the sandbox: Migrating an App to a Sandbox on developer.apple.com
This is done once the newly sandboxed app is launched the first time. If you can determine where the database was stored, you can migrate it into the sandbox.
I am trying to get my app submitted to the mac app store and I am having a bit of a design problem. Our app is an authoring tool and comes bundled with many projects created with the tool. Before the time of the app store, we would ship our app as an .img file which contianed a project directory and our app. Since I am only going to be submitting the .app file to the app store
with my app I am wondering where I should but the projects directory.
Initially I tried to put the projects directory inside of the bundle but this will not work because it is possible for the user to make changes to projects which might add new files to the project directory and this would make the sandboxing unhappy and mark the app as invalid.
What is the correct place to store such resources? I assume they should go inside the container? If so, what would be an elagent way to deploy this projects directory? Since we do not have installers in Apple land what would be the best place to deploy this projects directory? Do I just need to check on app launch if the projects are present and if not copy them from the bundle? This seems wrong.
Do I just need to check on app launch of the projects are present and if not copy them from the bundle?
Actually, this sounds right to me. As you said, the user cannot change/add any files in the app bundle. If you have resources there that the user needs to interact with, I would copy them to the ~/Library/Application Support/MyApp/ folder when they are needed. The user can then interact with the files from that location. (When sandboxed they go into a different but related location.)
I don't really know what your app does, but it would also seem like a possibly useful feature to "reset" the project files/folders back to a starting state. So copying the files in this way would allow for that kind of behavior as well.
The instructions given in the Distribution page on the iOS Provisioning portal clearly still describe the process of creating, and including the Entitlements.plist file in a build for an ad-hoc distribution. The iOS Development Guide's Distributing Applications page, on the other hand, makes no mention of the Entitlements.plist file.
When I tried to "Build and Archive" our latest app following the instructions from the iOS Development Guide, the resulting ad-hoc app.ipa wouldn't install on my development device, due to a problem with the entitlements. When I rebuilt with the Entitlements.plist file, the new app.ipa installed fine.
Unfortunately, including the Entitlements.plist in the app.ipa means that the resulting build can't simply be re-signed and submitted to the app store - Right? Instead, I have to rebuild without the Entitlements.plist and submit the result to the app store.
I guess that I really have a few related questions:
Would the app.ipa produced as directed in the iOS Development Guide (no Entitlements.plist, just sign with the ad-hoc distribution provisioning profile) install OK on a non-dev device that was properly identified in the test distribution provisioning profile?
Is there any way for me to test the exact results of a "Build and Archive" on my dev machine, so that I can just re-sign it and submit it to the App Store from Xcode?
Will an app.ipa that explicitly includes an Entitlements.plist file be rejected if I did submit it?
Thanks!
As of Xcode 4.2 you no longer have to create an Entitlements.plist file when creating applications that do not require any special permissions to run. The get-task-allow entitlement is automatically set to true or false, depending on what kind of provisioning profile you sign your application with (Developer, Ad Hoc, or App Store).
ref:http://help.testflightapp.com/customer/portal/articles/535398-invalid-profile-distribution-build-entitlements-must-have-get-task-allow-set-to-false-
i just tried , no need entitlements for simply ad-hoc , simply using ad-hoc profile to archive and share , then fine .
From the iOS Developer library:
If you're doing an Ad Hoc distribution, you must properly configure your project to include an Entitlements.plist file and uncheck the get-task-allow checkbox (which sets it to False).
http://developer.apple.com/library/ios/#technotes/tn2242/_index.html
There's no issue with leaving the Entitlements.plist file in the Distribution build, I've had several apps submitted with it.
Actually, Entitlements.plist is also for other iOS features that your app may use:
Entitlements. These files define
properties that provide your
application access to iOS features
(such as push notifications) and
secure data (such as the user’s
keychain).
http://developer.apple.com/library/ios/#documentation/Xcode/Conceptual/iphone_development/115-Configuring_Applications/configuring_applications.html
Also check this answer:
The executable was signed with invalid entitlements
Get-task-allow is now called "Can be debugged" in Xcode 4.1 if you've used the modernization tool
I don't have answers to all your questions, but I needed to add an Entitlements.plist when I recently used ad hoc distribution for some testing. I think the documentation still talks about the 'get-task-allow' setting in the .plist, but when I followed the instructions exactly I had problems signing the app. Instead, I created an Entitlements.plist using Xcode's template. It has two or three settings, none of which are get-task-allow. I left it exactly as it was when created, and the build succeeded.
My experience in the past has been that apps submitted to the app store with an Entitlements.plist included failed the verification step.
I have a Cocoa application for which I've changed the name. I'm using the excellent Sparkle Framework (http://sparkle-project.org) to provide updates to my users.
Unfortunately, it appears that Sparkle doesn't support application name changes out of the box. I'm hoping there is some hack so that I can provide users who already have the app with an update to the newly named version.
I'm not sure this is possible using only the vanilla Sparkle framework. The reasoning is that the file name of the application can differ from the CFBundleName defined in Info.plist. Sparkle needs to ensure it is updating the correct file system structure, no matter what it may be named.
Consider the following scenario:
User downloads and installs Adium.app whose CFBundleName is Adium.
User renames it to Instant Messenger.app.
Sparkle downloads and installs an update.
After the update, the file name of the newly updated app is still Instant Messenger.app and the CFBundleName is still Adium.
You can either hope that the fact that your application name has changed in the menu bar will prompt the user to rename it themselves, or your can pull some trickery at application startup to quit the application, rename it, and re-launch it if certain criteria are satisfied. I don't recommend the latter though, users do not like applications deciding to move themselves around without permission.