64-bit wird vorausgesetzt: Apples Entwickler-Ultimatum ab Februar

[Phoenix]

Naja, für die Apps ist das vielleicht wirklich nicht so nötig.

Aber wenn Apple vielleicht plant, in die nächste (oder übernächste) Geräte-Generation nur noch 64bit Chips zu verbauen (weil die vielleicht billiger sind, einfacher zu beschaffen, whatever), dann muss man als Entwickler halt nachziehen, weil sonst läuft es irgendwann eben nicht mehr auf dem iPhone vNext.

[mkinzler]

Es gibt auch anderes, was einem an dem nextgen stören könnte, aber grundsätzlich ist das System dass sie nun haben recht schwer zu warten und auch die langsame Anpassungsfähigkeit liegt imho darin begründet.

Wen man mindestens alle LLVM compiler auf der selben Version hätte.
Wenn nun ein ARMv8 compiler kommt, wird der hoffentlich nur als weiteres backend für den Delphi compiler für LLVM implementiert. Hierzu muss dieser u.U. aber an die neue LLVM version angepasst werden ( mit ARMv8 backend).

[mkinzler]

Zitat von Phoenix:

Naja, für die Apps ist das vielleicht wirklich nicht so nötig.

Aber wenn Apple vielleicht plant, in die nächste (oder übernächste) Geräte-Generation nur noch 64bit Chips zu verbauen (weil die vielleicht billiger sind, einfacher zu beschaffen, whatever), dann muss man als Entwickler halt nachziehen, weil sonst läuft es irgendwann eben nicht mehr auf dem iPhone vNext.

Man verbaut seit dem iPhone 5s nur noch 64Bit Chips, diese können aber auch (wie auch X64_64) auch alten ARMv7 32 Bit Code ausführen ( nund auch noch ältere ARM Code).

[himitsu]

Wenn ich mir die Kommentare so durchlese, vorallem

Zitat von Dennis:

Sie müssen 64-Bit unterstützen. Das schließt eine 32-Bit Unterstützung nicht aus.
Sprich, die alten Devices werden auch weiterhin unterstützt. Es wird lediglich eine Kompatibilität mit der neuen Hardware verlangt! Also wenn ein Entwickler eine neue App entwickelt, kann er diese nicht auf nur-32-Bit-Geräte festnageln.

Ein Win32-Programm läuft ja ebenfalls in einem Win64, also unterstützt man implizit das Win64, solange man nicht explizit etwas verwendet, das nur unter Win32 funktioniert.

Genauso würde ich das beim Apple-OS auch erstmal sehn, oder wird denn nun wirklich explizit eine 64-Bit-App verlangt?

Zitat:

Starting February 1, 2015, new iOS apps uploaded to the App Store must include 64-bit support and be built with the iOS 8 SDK, included in Xcode 6 or later. To enable 64-bit in your project, we recommend using the default Xcode build setting of “Standard architectures” to build a single binary with both 32-bit and 64-bit code.

[Stevie]

Zitat von himitsu:

Genauso würde ich das beim Apple-OS auch erstmal sehn, oder wird denn nun wirklich explizit eine 64-Bit-App verlangt?

Zitat:

Starting February 1, 2015, new iOS apps uploaded to the App Store must include 64-bit support and be built with the iOS 8 SDK, included in Xcode 6 or later. To enable 64-bit in your project, we recommend using the default Xcode build setting of “Standard architectures” to build a single binary with both: 32-bit and 64-bit code.

Ich hab die Markierung mal geändert, damit das klar wird

[himitsu]

In einer "EXE"?

Also sowas wie dieser komische Hack, wo DOS und Windows-GUI-Programme in Einem waren?




Dann wird das Kompilieren doch doppelt so lang dauern und die Binarys fast doppelt so groß, wenn alles doppelt drin ist.

[mkinzler]

Bei Apple gab es dies immer mal wieder ( 68K/PPC, PPC/IA32).

[Daniel]

Das ist kein Hack.
Die Apps sind letztlich ein Container-Format, in dem auch mehrere Binaries sauber und ordentlich nebeneinander liegen können.

[Darlo]

Dann hat ein Firemonkey iOS Rechner, der 2 Zahlen Addiert 40 MB

[Daniel]

Ja, die Grundlast durch FMX ist ein Problem. Dafür hat dann das Update, welches immerhin 3 Zahlen addiert, ebenfalls nur 40 MBytes.
Und wenn Du 10 weitere Formulare hinzufügst, kratzt Du vielleicht gerade mal an den 41 MBytes. Der weitere Zuwachs, wenn es eine "richtige" App wird, ist ja eher gering und wird eher über die zusätzlich integrierten Ressourcen wie Bitmaps und dgl. gesteuert.