Apple’s developer subscriptions have the ability to develop applications for
internal corporate use. At the same time, applications are not tested by Apple and are not required to “glow” in the AppStore. All of the above applies to
Ad Hoc applications, they are essentially no different, except that the lifetime after creation.
To distribute the application I wanted to solve the following tasks:
- the user could independently install the application on his device
- only authorized user could install the application
- simple publication of the application on the server
I will describe how to implement and what were the difficulties.
one.
With the first paragraph, everything is clear, there is
information on this topic. Those. We create the correct link to the plist file, and there should be a magic link to the ipa application archive.
')
2
The second point seemed not so difficult problem: create an authentication page and authorize the user. Next, give him a link to install / update the application. PROFIT.
In fact, it was not so simple. Session between Safari (I do not speak already about other browsers) and AppStore is not rummaged. A little thought and you can solve this issue - make session keys and pass them in the parameters of the link. Just make an analogue of cookies that are transmitted by GET and have a limit on the lifetime / number of times of use. Then I was waiting for another small nuance. As planned, the link to the plist looked like this:
https: //example.com/getapp? Key = F00DBEE & type = plist , to get the application itself, the type = ipa parameter. It turned out that when processing links, the device takes into account only the first parameter, the rest simply discards - offensively. But where ours did not disappear - all interesting data can be added in one parameter.
It is worth paying attention to one more trifle - before getting the AppStore application makes a request to the server using the HEAD method, and only then it downloads the GET file itself. In connection with this tricky trick, my session was “spoiled” when not necessary. Yes, the application itself was spat out twice, because used to content use HEAD === GET.
3
Reducing the amount of data to publish = reducing third-party errors. In the ideal case, the update would feature one application file - ipa, but the user often wants to know what changes were made to the application. So we stopped at the ipa version + description of the changes.
To install the application you need a plist, which describes the pre-installation properties. This XML file looks exactly the same (with a difference in parameter values) for different applications.
example plist<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>items</key> <array> <dict> <key>assets</key> <array> <dict> <key>kind</key> <string>software-package</string> <key>url</key> <string>__URL__</string> </dict> <dict> <key>kind</key> <string>display-image</string> <key>needs-shine</key> <false/> <key>url</key> <string>__SMALL_IMAGE__</string> </dict> </array> <key>metadata</key> <dict> <key>bundle-identifier</key> <string>__IDENTIFIER__</string> <key>bundle-version</key> <string>__VERSION__</string> <key>kind</key> <string>software</string> <key>title</key> <string>__TITLE__</string> </dict> </dict> </array> </dict> </plist>
These parameters can be obtained from another plist, located in the depths of the ipa file (which is a zip archive) of the application - Info.plist. The only drawback is that it is binary. MacOS has a good console
plutil utility for converting plist formats, but not everyone has MacOS on servers.
You can solve this problem by writing your converter, or
building a native application , or using the
Perl script , Windows can install Apple applications and find the console utility at “
C: \ Program Files (x86) \ Common Files \ Apple \ Apple Application Support \ ". The variant with its implementation is tempting, but expensive. I used Perl. After converting a binary plist, we get something like this XML:
bplist example <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>BuildMachineOSBuild</key> <string>14D73</string> <key>CFBundleDevelopmentRegion</key> <string>en</string> <key>CFBundleDisplayName</key> <string>MyApp</string> <key>CFBundleExecutable</key> <string>MyApp</string> <key>CFBundleIcons</key> <dict> <key>CFBundlePrimaryIcon</key> <dict> <key>CFBundleIconFiles</key> <array> <string>i57.png</string> <string>i114.png</string> </array> </dict></dict> <key>CFBundleIdentifier</key> <string>com.company.MyApp.ios</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>MyApp</string> <key>CFBundlePackageType</key> <string>APPL</string> <key>CFBundleShortVersionString</key> <string>1.0</string> <key>CFBundleSupportedPlatforms</key> <array> <string>iPhoneOS</string> </array> <key>CFBundleVersion</key> <string>1.0.3</string> </dict> </plist>
From the description we are interested in:
CFBundleVersion ,
CFBundleIdentifier ,
CFBundleDisplayName . This is the name, version, application ID, respectively. You can also extend the icon with a bonus. To get the values, use the following XPath
/ plist / dict / key [contains (text (), ' __KEY__
')] / following-sibling :: string [1] / text () where
__KEY__
necessary keys.
This way, you can distribute not only Enterprise, but also AdHoc without any problems.
Update application.
The application itself should keep track of the application update, since it is not part of the appstore. And in general, the b2b application needs to be monitored very carefully, it may still not be transferred from one device to another when dumping via iTunes. To update the application directly from the application itself, you need to open a magic link to the manifest (plist) in Safari that starts the file
itms-services: //? Action = download-manifest & url = .
As a conclusion.
In this implementation, perhaps only one crutch is the use of a third-party application for reading info.plist, the rest of the “gestures” can be accomplished without any problems on all (most) platforms / technologies, etc.