MVP Logo

Материализуя идеи

Не поднимешься в горы — не узнаешь высоты неба; не спустишься в бездну — не узнаешь толщи земли.

Recently, I've complete my 'geshtalt' - migrate and release Windows FMX app, Ecolight-AP under MacOSX platform. And, by God, it was painful and hard, mainly due to EMB toolchain tried to fracture my butt on almost each final step.
The dehydrated knowledge here is crystallized two weeks of pain and swearing, and sweatting.
Problem starts reveling itself after all Debug stuff was successfully brushed on MAC, under PAServer session, and Release for App Store was created with Developer ID * certificates, which allow to install from signed local pkg.

The deployed product just refuses to unpack stuff which should be delivered automatically by System.StartUpCopy module, effectively rendering an application unusable.
Even Normal (unsigned) release ran OK, if executed from app bundle.
After nearly a week of checking and double checking code (my first suggestion was that in Release, automatic StartUpCopy code is optmized-out, or executes at the wrong time), I finally started to think, that something is fishy with Release signing done by IDE deployment process.

All in all, I decided to perform each step manually. Some basics are described in Embarcadero's Manual Sandboxing OSX application.
When I tried to codesign a "Normal" app bundle, I start receiving "unsealed contents present at the root", which is a sign that some file or dir is placed outside the /Contents folder, which is a no-no.
ls -a on app bundle does not show anything, but /Contents. Though, executing the same in sudo session, revealed strange empty hidden plist file, like .app_id.Info.plist, where app_id is application identifier string.

I do not know which magic put it there, but the logical, and moreover, necessary, thing is to rm it under sudo: sudo rm "frigging hidden plist file".

Next step, we got to execute the following to codesign bundle with Developer ID Application identity.
sudo codesign -f -v --deep -s "<signing application identity>" "<absolute .app path>"
--deep option is needed to recursively sign all additional contents, otherwise, signer will complain that bundle contains some, say dylibs, which are not signed at all.

After codesign does it job, we got to create signed Installer pkg. This time, with Developer ID Installer signing identity.
sudo productbuild --component "<.app path>" /Applications --sign "<signing installer identity>" --product ".app path/Contents/Info.plist" "<appname.pkg path>"

If everything goes OK, which did in my case, youl'll get your pkg in scratch-dir folder.
After Installation is complete, you not only have app installed in Finder, but also, its startup code to unpack and deploy al necessary additional contents in their preordained positions.

If you plan to Deploy via AppStore, the 3rd part Application and 3rd party Installer identities should be used instead, as it briefly described elsewhere.

THat's all, folks, I got to drink a lot of valerian drops, and maybe something else. God, I even did not kill anybody in the process. It was close, though. Thank you, EMB.

Яндекс.Метрика

Сейчас 47 гостей и ни одного зарегистрированного пользователя на сайте

14.12.2019  ©2019 - ExactSoft - All rights reserved