Mac app store helper tool Sandboxing - app-store

My app consist of two executables
the main app executable
small console app to process some files, this executable is on Resources folder (no root privileges required)
The thing is that I don't know how to submit this app to appstore, I get the following response from apple
Invalid Signature - the main app bundle appname at path appname.app is signed but the signature is invalid. The following error(s) were reported from codesign:
a sealed resource is missing or invalid
In architecture: i386
If I remove helper app, it bypasses this error, but app won't work at all. Anyone knows a good way or example on how to embed a helper app and sign it corectly to appstore??
Apple docs are not clear on this.

You need to sign both main app and helper console tool
Signing .app is documented so I describe you how to codesign the helper.
Create by hand an entitlements file and add it to helper project (you can copy the one from main app and removing not necessary entitlements keys)
Create an Info.plist as documented at Adding an Info.plist to Single-File Tools (this step should be not mandatory but if you find the helper crash try to add it)
If main app launches the helper tool you should need to add
com.apple.security.inherit
this is described in Enabling App Sandbox Inheritance
If main app interacts with helper in some other manner maybe you need XPC communication or if you are lucky it will be sufficient to use App Group
Something like
<key>com.apple.security.application-groups</key>
<array>
<string>$(TeamIdentifierPrefix)my.package</string>
</array>
Take a look at AppSandboxLoginItemXPCDemo
From my experience TeamIdentifierPrefix must be empty on development environment and set to your team id when you submit to MAS, please handle with care my considerations on TeamIdentifierPrefix (i.e. try yourself)

Related

Catalyst app info.plist not being recognized

I am trying to submit my first catalyst app to the Mac App Store. I have setup the App Store information in iTunes Connect, and I have confirmed that the info.plist in app has the following key in it:
<key>LSApplicationCategory</key>
<string>public.app-category.business</string>
However when I go to upload to the app store I get the message that I need to add the LSApplicationCategory
ERROR ITMS-90242: "The product archive is invalid. The Info.plist must contain a LSApplicationCategoryType key, whose value is the UTI for a valid category. For more details, see "Submitting your Mac apps to the App Store"."
I have confirmed that both public.app-category.business is correct, and I have also tried using the value "Business". I get the same error message. Is there something else I need to look at?
The key which you are adding to .plist file is wrong. Add below key-value pair. Full list here.
<key>LSApplicationCategoryType</key>
<string>public.app-category.business</string>
slicerdicer's recommendation worked for me. To add some additional detail, you can also set the App Category by going to Project / Targets / General. It's the very first option.
I had sucsessfuly upload two apps using catalyst then the third failed with that error. I found this and seemed to work.
To the info.plist add App Catagory with what ever catagory your app fits. I used Productivity.
I was converting an iOS app to a Mac app, and I was updating the file info.plist, and it was not actually updating the overarching project.
I ended up having to go to the overarching project, under the left side TARGETS tab, I selected my app, went to the Info tab, and added the App Category there.

iOS OTA install not registering custom URL scheme

For one of our clients, we have developed an OTA app store for distribution.
To enable testing if the apps are installed, in each of the apps I wrote, I added two custom URL schemes: one that's just the app id, and one with the app id and the version (both with . replaced by -); so for example com-mycompany-app and com-mycompany-app-1-2-0 for com.mycompany.app, version 1.2.0.
Then, in our "app store" I just use [[UIApplication sharedApplication] canOpenUrl:] to determine if an App is installed or the latest version, and if so, replace the "Install" button with an "Open" button.
When installing the app through XCode, it works great. However, when I install the same app OTA, through my "app store", the canOpenUrl: call always returns NO. To see if it was a caching thing, I have tried restarting the "app store" app after OTA install has finished, but I get the same results.
Is this an issue with my manifest plist file? In the Info.plist that belongs to the target, the custom URL Scheme stuff is obviously there, but it's not in the manifest's. However, I would imagine it only uses the manifest to launch initial install...shouldn't the Info.plist be used during actual install to register these sorts of things? Is there something else I'm missing?
Thanks!
Edit: I'm using a custom build script to actually create the .ipa and .plist files that are being used for OTA distribution. I tried using iPhone Configuration Utility to install the IPA directly, and my app store was able to recognize those URLs as being openable. The only possible things I can think of are either that the plist I'm using to download & install needs to have some sort of reference to these custom URL schemes, or it's actually a legitimate bug in Apple's OTA framework.
I got this working, in case anyone is watching this or stumbles upon a similar issue.
The only thing I changed -- and there's no documentation saying the old way wouldn't or shouldn't work -- was to use periods in my URL scheme, instead of hyphens. So com-company-app:// became com.company.app:// (same as the bundle ID), and likewise with the version-appended one.
I don't know if my old URL schemes were violating official URL spec, or if you're supposed to use reverse-DNS, but everything is working, now.

How to codesign automatically generated iOS apps?

Greetings,
I'm in the progress of writing a web server script that lets you create custom iOS apps (basically exchanging logos and a few other things). The web server customizes a previously uploaded "shell" .ipa and re-zips the whole container to send it to the user's browser. That is: we customize a previously uploaded .ipa on the web server and let the user download it for submission to the App Store.
The next step would be to re-codesign the whole .ipa - because we changed the .IPA contents and the user must use his own signing identity - so that he can actually upload it to the App Store.
From what I understand, there is a "CodeResources" file which contains some kind of hash for each resource file in the bundle, and the executable contains some kind of embedded signature as well. To generate these, you'd have to use the "codesign" utility on the user's computer, then use Application Loader to submit it to the App Store. Correct so far?
What I'm trying to find out is:
Is there a way to codesign the .ipa on the server (with having the user upload his certificate beforehand), so that he does not have any extra work to do?
If 1) is not possible, is there some kind of tool that allows to re-codesign the .ipa without much hassle? Xcode seems to require some project setup work to do just a bit of code signing - if possible at all.
Are there any alternative ways to codesign the .ipa files for the user - possibly without having to manually do it by hand?
Thanks in advance!
Xcode uses the codesign command line utility to create the CodeResources folder and the digital signature, you can invoke it yourself to sign an app bundle outside of Xcode. You could probably automate this on a server if the server was running Mac OS X; if you're really clever you might be able to figure out how to create the signature yourself using openssl (the signing certificates, etc. are all standard stuff). Or, if you can count on the user having the dev tools installed, provide them with an app that automates the signing for them.
Here's a blog entry describing some of the process (though the use case is a little different).
I don't like to answer my own question, but I want to close this after so long.
We ended up using Xcode's targets and schemes to ease up the generation of many different apps. Since we have a reasonable number of app variants, this seems to be OK for now.
Code signing is a mess and Apple constantly changes the technical process behind it - so it's a moving target and requires a lot of hacking and trial-and-error work.

How to build an app for Cydia store?

I have built an app for Apple's App Store, now I want to submit the app to the Cydia store. How can I do this? Should I just post the app.zip file built for the App Store to the Cydia store?
There are a few differences compiling your app for Cydia vs the App Store. Big Boss does a good job explaining the difference in his post:
How to Compile for Cydia Submission
You should check out iOSOpenDev. It incorporates a lot of Cydia tweaks, Theos, Activator and all kinds of other things into Xcode. It allows you to create a new (Cydia) tweak of your choice and you can even launch that tweak on your device from Xcode.
To submit an "App Store" app, you would need to make sure you adjust the user directories. Since you will install the app into /Applications, there will be no sandbox; no Documents directory dedicated to just your application.
You will also need to sign your app with ldid. This "fake" code-signs your application so it can run in iOS. To submit the app to Cydia, you would need to find a repo you are comfortable with hosting the app, like BigBoss.
Be careful though, submitting an App Store app to Cydia could potentially get your app thrown out of the App Store and your developer account revoked.
In terms of building an actual full application, I believe the development process is the same but the compiling and preperation of the binary is different. The provided link is a good resource
If you intend to make a tweak which hooks into existing Apple classes and methods then you need something like theos by DHowett, a good basic tutorial is here
u need to create a repo. or send them to MMi's collection
to make a repo read Saurik's Guide: Here
Or read the easier guide that MYI made for us at: Here
to submit a package to the MMI repo,
try the Developer Portal:
http://modmyi.com/mmi/
Some info regarding paid packages:
http://modmyi.com/cydia/cydiastorefaq/
Basically, all the content in your theme must be your own original work.
All the graphics / sounds must be created and owned by you.
If you have further questions, drop a note to the admins:
http://modmyi.com/sendmessage.php
Well first of al if your app.zip is the .app file found in the payload folder of a .ipa file, then disregard this next step. Anyway, open up app.zip, go to payload, and then take out app.app. Make the app.app app.zip. Now go to http://www.myrepospace.com/iDeb and upload your app.zip. Then when it's done, download your new .deb file.
Despite of the title you seem to ask about submission rather than (or in addition to) building. I'd consider this the one best reference:
http://cydia.saurik.com/faq/repositories.html
It is from Cydia itself and includes sschunara's links and other BigBoss references plus more.

Updating resource files for iPhone app

I've developed a generic iPhone app, intended for customization via a myapp.cfg file. I've successfully deployed the app to my adhoc testers via iTunes. My question is, how do I update their myapp.cfg file via iTunes. In other words, if they edit the .cfg file on their Windows PC or Macbook, how do they get it into the apps bundle in the iPhone?
You'll need to provide your own mechanism to download the config file into the application's Documents area; as app bundles are effectively sealed by the code signing process there's no way to modify the bundle post facto. As you have no interface to iTunes you need to provide your own mechanism - you might choose to do something like OmniFocus which uses Bonjour to discover the computer from which it retrieves its sync settings.
Looking at it another way; why use a config file at all? Other iPhone applications use a settings bundle and the standard application preferences as recommended by Apple, why do something different? There's always a chance that you'll confuse the user.