Code macht kaum einen Unterschied, Grafiken und andere Ressourcen sind viel ausschlaggebender

Das ist auch der Grund wieso einige apps ein zweites Mal angeboten wurden.
Das zweite Mal war die "unverschlankte" Version.

Interessante Gedanken und Ausführungen zum Thema grad' vor dem Hintergrund des aktuellen Desasters bzgl. XcodeGhost:
Quelle:

Frederic Jacobs (24.09.2015): Why I’m not enabling Bitcode
Thoughts on application binaries packaging and software distribution

In Bezug auf den Code hat das andere Gründe.

Optimierungen auf die CPU im Ziel-Gerät und das nicht unbedingt auf A7,A8,A9,… sondern, zumindest in der Theorie ist es möglich, verschiedne Architekturen mit einer "Codebasis" zu unterstützen.

Apple könnte z.B. so verrückt sein und ein iPad mit x86-CPU oder MIPS rausbringen … die Devs müssten dafür aber absolut nichts machen. Alle Apps laufen ganz normal, der User merkt davon nichts.

Ja, wir sehen die Vorbereitungen für OS X+1 auf ARM. Wenn erst einmal alle Frameworks auf beiden Architekturen laufen (wie Metal), wird die Umstellung nicht einmal mehr ein neues Rosetta brauchen.

Ich vermute mal, dass die Resourcen dann auch nur noch 1/3 so viel Platz brauchen. 2 Auflösungsstufen können ja wegfallen.

Am besten auch keine 16GB iPhones kaufen. Schon als Signal. Aber irgendwie fördert auch die Hochpreispolitik mit.

Ich finde das eigentlich lächerlich. Warum bietet Apple nicht einfach mal das 32GB iPhone als kleinste Version an und die größeren Geräte gegen einen adäquaten Aufpreis?

sierkb

Er hat ja völlig recht, nur unterscheidet sich das exakt gar nicht von der aktuellen Situation.

Apple kontrolliert derzeit Entwicklungsumgebung (incl. Compiler und Linker), Binärformat, Entwicklerzertifikate (incl. Root-Zertifikat) und Binarydistribution. Es gibt exakt nichts in dieser Kette, das Apple davon abhalten könnte an einer beliebigen Stelle beliebigen Code in genehme Apps zu injizieren.

Andererseits ist der Bitcode ja weiterhin mit den Entwicklerzertifikaten beglaubigt, dass heißt für Außenstehende ist es auch mit Bitcode exakt genauso leicht oder schwer fremden Code zu injizieren.

das stimmt so nicht, denn man kann im code weichen für verschiedene CPU-typen einbauen, bzw für 32/64 bit, für big-little-endian etc. Wenn das nicht gemacht wird, dann wäre sowas möglich (natürlich nur wenn so ein system die gleichen APIs haben würde).

Wenn das so leicht wäre, warum mussten dann bei der OSX Umstellung von PPC auf Intel "Universal Binarys" von allen Programmen her, obwohl die APIs identisch waren? Verschiedene CPUs haben verschiedene Eigenschaften, die schon beim kompilieren beachtet werden müssen.

Ich war heute in einem euronics elektrohandel. Dort lagen noch schätzungsweise 10 iPhone 6s mit 16gb als regelrechte Ladenhüter rum. Alle anderen Modelle waren natürlich vergriffen.

Hui, hier geht jetzt einiges durcheinander. CPU-Codeweichen haben mit Universalbinaries exakt überhaupt nichts zu tun.

Die Codeweichen sind ja exakt dafür da, CPU-Spezifika zu berücksichtigen. Trotzdem werden natürlich vom Compiler je nach CPU zwei völlig verschiedene Binärdateien erzeugt. Diese Binärdateien werden dann in den Universalbinaries zusammengepackt, und der ausführende Rechner sorgt dann dafür das richtige Binary zu starten.

Hier setzt nun der Bitcode an. Der Compiler auf dem Entwicklerrechner übersetzt nicht mehr direkt in Binaries, sonder in einen universellen Zwischencode (ähnlich z.B dem "kompilierten" Java-Code). Bei Java wird dieser Code auf jedem Endgerät dann (durch die JVM) in Binärcode übersetzt. Beim Bitcode, wird dieser Code vom AppStore in die verschiedenen Binärformate übersetzt und dann ausgeliefert. Daher ist die CPU des Endgerätes in beiden Fällen (Java oder Bitcode) irrelevant. Der Unterschied liegt darin, das bei Bitcode das Endgerät nicht mehr für die Übersetzung Zeit und Energie aufwenden muss. Ein ähnliches Konzept bzgl. Java und Android hat Google mit Android 5.0 (oder 5.1?) eingeführt. Dort wird die Kompilierung direkt nach dem Herunterladen einmalig auf dem Endgerät durchgeführt, statt bei jedem Programmlauf.

mazun

Die 16-GB-Teile können und werden noch recht lange herumliegen. Für Apple erfüllen die ihren Zweck als Preissteigerungsargument. Wenn mit Wegfall der Grundstufe das Treppchen zur Spitze kürzer ausfällt, würde der ohnehin nicht leicht zu verargumentierende Preissprung mit jeder Speichererhöhung dem Kunden noch gieriger erscheinen.

damn, apple könnte auch 24 GB modelle bringen.👹😡

grrrrrrr

Walter Plinge
Sehr gute Erklärung, finde ich! Nur mal eine Frage als "interessierter Laie": ist das mit dem Bit-Code nicht schon eine uralte Idee? Zumindest meine ich mich an den Begriff "Byte-Code" erinnern zu können, und rein gefühlt muss das mindestens in den 90ern gewesen sein.

chessboard

Die hast ganz Recht, die Idee ist uralt, und stammt aus den 90ern. Der kompilierte Java-Code heißt Bytecode, und ist etwas ganz ähnliches.

LLVM hat dieses Konzept auf die Compilerentwicklung übertragen, und den Sprachparser (C, C++, Objective-C, Swift, etc.; das Frontend), vom CPU-abhängigen Teil (dem Backend) zu trennen. Dazwischen hat LLVM eine "Zwischensprache" gelegt. Diese Trennung macht sich Apple jetzt also bzgl. Bitcode zu nutze, um für seine Mobilgeräte optimierten Code ausliefern zu können.

Walter Plinge:

Interessant auch die durchaus kontrovers geführte Diskussion und die Argumente dafür und dagegen unter .

Beispiel:
Zudem ebenfalls lesenswert und passend in die Diskussion hier und Deine obige Erklärungen und Erläuterungen unterstützend:

Low Level Bits (05.09.2015): Bitcode Demystified

Auch dieser Autor hat in seinem insgesamt sehr interessanten und gut erklärendem Blogeintrag u.a. diesen Abschnitt "What problems Bitcode introduces?" und beginnt ihn mit:

und führt das weiter aus.

sierkb

Vielen Dank für die Links. Vor allem die Diskussion zu den Sicherheitsimplikationen des Bitcode ist sehr interessant.

Ach deswegen ist nach dem Update auf iOS 9 sogar noch eine Spur weniger frei, als vorher. 😕

Hatte das Update so früh gemacht, weil ich mich auf mehr freien Speicher gefreut habe! (Aktuell ca. 3 GB bei 64GB iPhone 6)

Ich hoffe nur schwer, das kommt bald! Backup in die Cloud nutze ich sowieso nicht.

3GB frei auf einem 64 GB iPhone? Was schleppt ihr denn alle herum? Runtergeladene Musik, Filme? Fotos können es ja nicht mehr so arg sein. Vielleicht mal ein paar selten benutzte Apps löschen? Ich habe von meinen 64 Gb weit mehr als die Hälfte freien Speicher übrig und mache ständig Fotos und lade Musik fürs Auto offline herunter. Würde mich mal interessieren, ob es die Anzahl Apps (große Spiele) ausmacht oder andere Dinge?