Anyone using cmake for iOS development?

René J.V. Bertin rjvbertin at gmail.com
Thu Mar 14 22:20:37 UTC 2019


> Apple requires each app to specify that it supports Retina mode. 

AFAIK applications have always existed that set NSPrincipalClass to NSApplication; do these now behave incorrectly on high-dpi screens if they don't contain any modifications to their code? Somehow I doubt that.

> MacPorts and CMake should not second-guess Apple about that. Some apps may not work correctly in Retina mode, and we and CMake should not break those apps by defaulting to Retina mode.

Again AFAIK: the Info.plist just informs the OS whether or not an application is capable of supporting a high-dpi mode (NSHighResolution*Capable*), it doesn't actually activate the mode.

The only scenario where this can go wrong is where having an INappropriate NSHighResolutionCapable=true in the Info.plist (implicitly or explicitly) imposes a software DEactivation of the high-dpi mode very early in main.

Cmake reverted the change that enabled default high-dpi support not because of such issues but because NSApplication is not approprioate on iOS and other embedded Darwin variants.

I guess I'll get flak for adding the NSPrincipalClass magic to my cmake port if that causes inappropriate behaviour in certain applications.

> NSApplication supports Retina mode, so Apple enables Retina mode when this key is present in the Info.plist

How many applications do you know that are built as app bundles via cmake but do not use NSApplication no matter how deeply hidden in a middleware like Qt? My guess would be that there will be less ports where the NSPrincipalClass key has to be patched OUT of the Info.plist than ports where it should be patched into that plist in order to get proper high-dpi rendering.

> Setting this key to any value in an application that does use NSApplication would be inappropriate, but doing so will
"does NOT use" I presume?

> 2. NSHighResolutionCapable can be set to 1. This is what should be done in applications that do not use NSApplication.

I already wrote and submitted a patch to introduce a new key with a modifiable default (LSUIElement). Repeating the exercise for NSHighResolutionCapable would be trivial.

R


More information about the macports-users mailing list