I have a very big APP on MacOS , > 1 GB.
I want to create a miniature version of this app with minimal functionalities.
When user wants extra functionality , I want that extra bundles are added to this app so that it becomes equivalent to my original app.
How can I achieve this considering code sign and notarization issues.
I dont want to place these bundles outside the app so that after expansion my minimal app becomes exact copy of original bigger app - otherwise would need to create separate update pkg for both the kinds.
Related
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.
I've got an OS X app that I'm distributing outside the App Store. Currently, users go to my website and download a .zip file which contains the code-signed app within. It's very important to me that users don't have to register or create accounts to use my app.
My problem is I'd like to build out referral codes into my app as a way to encourage sharing. Ideally the flow would be something like:
User A opens the app and goes to a menu option to get a unique referral link based on a UUID (to avoid collisions).
User B goes to the unique referral link and downloads the .zip, which is a specially crafted version of the app that contains the referral code. Magic referral behavior is unlocked for User B.
I'm not really concerned about users cheating the system since the code is open-source and the app is free. But since the app is code-signed I can't change it at all (and I definitely don't want to go down the rabbit hole of trying to get my Heroku server to inject a referral code and then re-sign the app), but I'm not above sneaky things like adding the referral code to the name of the app, re-zipping it on the server, and then having the app inspect its own name to extract the referral code.
That, of course, is ugly.* Are there other ways I can cleverly add the referral code to the file metadata? Or is there some completely different approach I can take to otherwise achieve my goal? No solution is too hacky!
* Ugly to the user, that is. We're way past the point of worrying about ugly architecture.
How about not zipping the app until the referral link is called. Generate an external file with the code and zip that with the app then redirect to download the newly created archive. This is relatively easy using server side scripting. You can embed the code in the file and name the file consistently every time so that when downloaded, the app looks for the file, extracts the code as necessary and deletes the extraneous file.
After some experimentation, it appears that among all of the metadata present on files, the only field that's reliably set on different systems (since my Heroku servers don't run OS X) and reliably preserved through the zipping process is the touch timestamp.
I haven't quite gotten the code to completion yet but the current plan is to have the server modify the timestamp of the .app before zipping, and then the program inspects its own timestamp to find its referral code.
If that doesn't work I'll probably go with #Jon's solution above.
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.
I want to create books for the iPad.
I also want to be to write an app that will give access to those books
and allow me to add more books, without having to re-download the entire app.
My idea is to have a Main project that shows all the available books.
then a separate project for each book which will be downloaded individually (like a sub-project).
Is this possible?
If so, how will I be able to merge the main project with the "sub-project"?
if not, how will I be able to achieve this?
I saw something similar on an app called "Interactive Touch Books for Kids"
I'm using xcode 4.3 and cocos2d.
As far as Xcode projects is concerned, these apps will all be separate Xcode projects. The only thing you can (and should) share is common code, for example the cocos2d library. You do that by creating a static library target for the commonly used code.
As for your main app, keep in mind that you can not instruct the App Store to download another app on your behalf. The user experience will have to be that once the user clicks on a book to download it, he is taken to the App Store app where he can download the book.
In case I mis-understood you and you want all of the books in the same app, you need to implement In-App Purchases to either unlock or download additional content. Regardless of how you setup your Xcode project for that app, users will always have to download an update for your app if you add a new book or make modifications to an existing one. Unless you implement content downloads. But that has nothing to do with the project setup in Xcode.
I'm researching the best approach to automating our build process. I've got my own ideas (through experience on a previous non-iOS project) but need good arguments for and against various possibilities.
Objective: A single xcode project with a single target (think white-label) needs to be built in 1..N different flavours (concrete brandings) with minimum user interaction and minimum technical knowledge. For AdHoc and/or AppStore.
Essentially, that will mean specifying per build; a folder containing Icons + Splashscreen, a bundle containing brand specific resources and (presumably?) the Info.plist, specifying appname, bundle-id, etc.
Issues that need to be respected or clarified;
Manual build of a single brand via Idiot-Proof GUI (choose a git
branch/tag, specify a certain brand, configure the app e.g.
IAP-enabled, server-domainname, etc - will be written to the
info.plist)
In previous manual tests, setting the executable name in
the plist didn't work? Sorry, have forgotten the exact problem..
perhaps was only an Xcode Debug buildconfig problem, not relevant to
a distribution build?
Code-Signing?!? Can the profile be specified
on-the-fly? Some brands need to be built with the customer's own
profile.
My personal feeling: Hudson or CruiseControl + Xcode plugin.
There seems to be plenty of documentation around for an Xcode solution and I've seen this in action on a Flex project I worked on, with almost exactly the same white-label/branding requirements. Of course that was using Ant script though and there was NO behavioral config to respect. That's my only uncertainty here... I suspect it would have to be hardcoded somewhere, but that's not the answer that's going to please some people. There is a wish to be able to specify the various app-config settings (server url, is function Foo supported, is the view X displayed, etc, etc) via a GUI form, when building manually. I'm not sure how easy it would be to shoehorn that into a typical Hudson or CC config?
And hence one suggestion that has been made is to write an OSX app for building our clients. The theory being, nice clean non-tech UI for entering all the necessary meta data & app setting and a big shiny green button labelled "Build". But personally I'm skeptical that this approach is any more flexible or easier to implement than a classic CI solution.
So the question is basically, what's preferable; a classic server based, version control integrated, CI approach or a custom OSX utility?
Whichever we go for it'll almost certainly be a requirement to get it up and running in 2 or 3 days (definately less than one week).
IMHO you can resolve all issues using different targets of XCode.
Every target will share the code but it could:
be signing with diferent profiles
use diferent plist: this implies having different names..
use diferent brand images. You only have to name the image with the same name and select the correct target in file inspector.
Build with one click in XCode.
I hope this helps
An extremely later reply, but the approach I would take would be to create the white label IPA, and then create a script to:
1. Unzip it (change the .ipa file extension to .zip).
2. Change assets.
Update the info.plist (using Plistbuddy command)
Zip it again.
Resign the code.
See this script as a starting point: https://gist.github.com/catmac/1682965
Very late answer. But I would go with different .xcconfig files and multiple schemes. The scheme names could be a combination of target/brand.