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

[SvB]

Hab das hier gerade gelesen: 64-bit wird vorausgesetzt: Apples Entwickler-Ultimatum ab Februar
Kompiliert Delphi XE7 schon 64-Bit iOS Apps?
Wenn ich das richtig recherchiert habe, dann bisher noch nicht, oder?

[Sherlock]

Bisher gibts aus XE7 nur 32Bit iOS-Apps. Und wenn ich die Verfechter der halbjahres Releases korrekt verstanden habe, dann wird das auch so bleiben, denn XE8 steht ja dann fast schon bereit.
https://plus.google.com/111699935711...ts/htNWdWRYxTG

Sherlock

[mkinzler]

XE7 kam vor knapp 2 Monaten raus, also sind es noch 4 Monate bis zum Release der nächsten Version. Ist trotzdem recht unwahrscheinlich, dass man dann die 64 Bit Version sieht.
Zumal diese ja nicht auf der Roadmap steht ( nue für OSX)
http://edn.embarcadero.com/article/43677

[Daniel]

Ach, das könnte "ein wenig" Druck auf EMBT ausüben, die Roadmap den neuen Gegebenheiten anzupassen.
Viel Wahl hat EMBT ja nicht. Selbst wenn Apple - warum auch immer - die Frist nach hinten verschieben sollte, so ist es ja dennoch nur eine Frage von vergleichsweise kurzer Zeit.

[Der schöne Günther]

Ich kenne mich mit Apple-Entwicklung nicht aus. Kommt das überraschend? War es z.B. bei Bildschirmauflösungen in der Vergangenheit nicht ähnlich dass man noch eine kurze Schonfrist hatte und dann das neue unterstützen musste?

[Daniel]

Streng genommen ist die gesamte 64bit-Architektur auf Smartphones - und selbst Tables - absurd für 9 von 10 Anwendungen. Aber das hilft jetzt auch nichts. ;-)

[Darlo]

Zitat:

Zitat von Daniel (Beitrag 1276790)

Streng genommen ist die gesamte 64bit-Architektur auf Smartphones - und selbst Tables - absurd für 9 von 10 Anwendungen. Aber das hilft jetzt auch nichts. ;-)

Mich würde die 10 von 10 Anwendungen interessieren. Oder sieht Apple ihre mobilen Geräte nur noch als Spielkonsolen??

[Daniel]

Ich selbst wäre ebenfalls mit 10 von 10 zufrieden. Interessant sind natürlich Apps wie der kürzlich auf dem Event gezeigte Video-Renderer, der in Echtzeit Effekte in die Videos fuddelt. Ich halte es für plausibel, dass dies für End-Anwender interessant ist, Fotos und Videos buchstäblich mit einem Fingerstreich zu manipulieren und denke, dass dort noch am ehesten Bedarf an massiver Rechenleistung existiert.

[mkinzler]

Vielleicht habe ich mich etwas missverständlich ausgedrückt. Ich meinte nicht, dass es nicht kommt weil es nicht auf der Roadmap steht (Roadmap nicht änderbar), sondern das man wahrscheinlich bisher nicht daran arbeitet. Im Gegenteil ist die Roadmap ( zumindest die offizielle öffentliche) zu wenig verbindlich/strategisch.

Man hat vor Jahren schon erkannt, dass es sinnvoll wäre eine Frontend/Backend Compilerstruktur zu haben, in der für jede Sprache ein Frontend und für jede Plattform ein Backend besteht. Man hat damit mit dem Win64 Delphicompiler begonnen, der Win32 Compiler blieb (bis heute der "alte" Compiler). Der Compiler für OSX (32 Bit) basiert auf dem Win32 Complier. Mit dem nextgen Compiler hat man dann auf die LLVM Infrastruktur gewechselt, für welche man "nur" noch das frontend entwickeln muss, da die backends für viele Plattformen schon vorhanden sind. C++ verwendet nun auch LLVM aber neuere Versionen ( 32Bit/64Bit).

Praktisch hat man sein Ziel der Vereinheitlichung verpasst, da man weiterhin für fast jede Plattform getrennt entwickeln muss ( Nur der arm7 compiler wird für iOS und Android erwendet).

Delphi compiler für Win32
Delphi compiler für OSX32
Delphi compiler für EMBT frontend/backend mit backend für Win64
Delphi compiler für LLVM (iOs/Android backends)
C++ complier für LLVM
C++ compiler für LLVM (64-Bit)

Hoffentlich entwickelt EMBT dann den neuen compiler auch für Android.

Für eine neue Plattform wurde weiterhin ein neuer Compiler entwickelt, die alten blieben so, wie sie waren ( die 3 Compiler für LLVM verwenden 3 verschiedene LLVM versionen). Langfristig sollte dieser Wildwuchs aber beseitigt werden, da die weiteren geplanten Plattformen den Rahmen dann sprengen werden.

[Stevie]

Zumindest, was 32-bit angeht, bin ich froh, dass das noch der "alte" ist, wenn ich mir die Grottenperformance der Nextgens anschaue (die afaik größtenteils in der LLVM Architektur begründet liegt).

[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:

Zitat von Phoenix (Beitrag 1276806)

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:

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? :gruebel:

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:

Zitat von himitsu (Beitrag 1276811)

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

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. :stupid:

[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 :duck:

[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.

[RWarnecke]

Die Probleme habe ich alle nicht mehr, ob 64bit oder nicht oder welche XCode-Version. Ich habe meine Projekte auf XCode umgeschrieben bis auf eines. Da sich aber an der iOS-App nichts mehr so schnell ändert, werde ich diese Delphi iOS App so lassen wie sie ist.

[creed steiger]

Der lange Stillstand bzw. Windows+32bit fixierung fällt EMB halt gerade auf die Füsse.
Da hätte eine Weiterentwicklung oder ein Umdenken eher stattfinden können.
Jetzt ist es halt schwer/umständlich das Verpasste aufzuholen.
Wissen und Erfahrung aufzubauen braucht halt Zeit.

Mal sehen was aus dem eingeschlagenen LLVM Weg wird.

[Der schöne Günther]

Ich glaube "Der lange Stillstand" war noch vor Embarcadero.

Ich kenne mich mit Compilerbau kein Stück aus, aber ich war auch verwundert warum auf einmal C++ doch als allererstes auf LLVM war, aber nur in 64 Bit. Dann C++ erst nur iOS konnte, Android erst später. Irgendwie ist da der Wurm drin.

[divBy0]

Ich arbeite mich gerade in Xcode ein, da mir iOS und Mac OS-Geschichte mit Delphi auf die Nerven geht. Beruflich ist Mobilentwicklung bei uns kein Thema, privat ist mir das zu teuer, seit dem das Mobile-Pack dazu gekauft werden muss.

Vielleicht kommt ja durch das Apple-Ultimatum etwas Bewegung in die Sache, aber der Preis ist leider zu hoch.

[Darlo]

Firemonkey hat sich super entwickelt und 64 bit wirds auch noch schaffen. Alles bisschen zeitnaher wäre wünschenswert.
Werde ein größeres Projekt für Win und iOS wieder mit FM umsetzen, auch wenn ich bei Einigen Sachen auf iCL zurückgreifen werde. Aber die einheitliche Codebasis und das umgehen von objektive c ist ne geile Sache.

[RWarnecke]

Zitat:

Zitat von Darlo (Beitrag 1276888)

...das umgehen von objektive c ist ne geile Sache.

Ich habe mir auch zuerst gedacht, es ist nicht schlecht die Apps mit Delphi zu erstellen. Aber dann die ganzen Hindernisse und Kompromisse die man mit Firemonkey eingeht, waren mir das nicht mehr Wert. Ich lerne jetzt seit der WWDC Xcode und ich muss sagen, ich werde von Tag zu Tag besser. Dann die Möglichkeiten die sich auftun etwas umzusetzen, finde ich in sehr vielen Fällen in XCode besser gelöst als in Delphi. Ich für meinen Teil werde weiter XCode und jetzt auch noch Swift lernen, damit meine Apps deutlich besser werden als mit Delphi.

Ein ziemlich krasser Unterschied ist alleine nur das iAd Banner. Ich erziele deutlich bessere Werte mit einer XCode App als mit einer Delphi App.

[Sherlock]

Zitat:

Zitat von RWarnecke (Beitrag 1276901)

Ein ziemlich krasser Unterschied ist alleine nur das iAd Banner. Ich erziele deutlich bessere Werte mit einer XCode App als mit einer Delphi App.

Magst Du das erläutern? Was ist bei wem wie anders?

Sherlock

[RWarnecke]

Zitat:

Zitat von Sherlock (Beitrag 1276960)

Magst Du das erläutern? Was ist bei wem wie anders?

Ich kann es gerade nicht mit Zahlen belegen. Aber die Differenz zwischen den Anforderungen und den Impressionen des iAd Banners ist bei einer Delphi iOS-App deutlich größer als bei einer XCode iOS-App. Sobald die iAd Workbench wieder zur Verfügung steht, kann ich hier mal den Unterschied von meinem Sprit-Rechner (XCode) und BTCCalcMon (Delphi) posten. Bei beiden Apps wird das iAd Banner gleich beim Start der App angezeigt.

[Wunni]

Ich bin schon lange auf Xcode/Objective C umgestiegen und habe es nie bereut. Wenn jetzt die 64Bit-Geschichte wieder zum Kaufzwang einer neuen Delphi Version wird, dann sehe ich mich wieder einmal bestätigt. Xcode ist kostenlos.
Schaut Euch mal die Lernvideos von Frank Jüstel an, wie einfach die Entwicklung mit XCode eigentlich ist.

https://www.youtube.com/channel/UCjc...w?spfreload=10

[RWarnecke]

Auch die Videos von Learn2XCode sind nicht schlecht, damit habe ich angefangen.

[eddie11]

Ok, XCode hab' ich vor drei Jahren auch schon mal versucht, war ziemlich schwierig einzusteigen, hat aber letztendlich ganz gut gefunzt. Als dann XE2 kam fand ich das ganz chic, wieder mit Delphi rummachen zu können... Jetzt hats aber bis XE7 gebraucht um halbwegs zu klappen. Ich überlege jetzt auch ernsthaft eine Alternative zu suchen. Xcode/Swift scheint ganz gut geeignet zu sein, noch dazu kostenlos.

Aber was nacht ihr mit Android? Entwickelt ihr doppelt oder lasst ihr Android weg?

[RWarnecke]

iOS & OS X ==> XCode
Android ==> Android Studio
Windows ==> Delphi

So mache ich es jetzt, nachdem ich eine Delphi iOS-App auf Objectiv-C portiert habe und merkte, dass in XCode doch einiges besser lief als unter Delphi. Das gleiche gilt auch für Android.

[Sunec]

Zitat:

Zitat von RWarnecke (Beitrag 1279305)

iOS & OS X ==> XCode
Android ==> Android Studio
Windows ==> Delphi

So mache ich es jetzt, nachdem ich eine Delphi iOS-App auf Objectiv-C portiert habe und merkte, dass in XCode doch einiges besser lief als unter Delphi. Das gleiche gilt auch für Android.

Hattest du für die iOS Entwicklung mit Delphi die Standard-FMX-Komponenten benutzt oder Wrapper, wie beispieslweise: TMS iCL oder DPF

[eddie11]

Zitat:

Zitat von RWarnecke (Beitrag 1279305)

iOS & OS X ==> XCode
Android ==> Android Studio
Windows ==> Delphi

So mache ich es jetzt, nachdem ich eine Delphi iOS-App auf Objectiv-C portiert habe und merkte, dass in XCode doch einiges besser lief als unter Delphi. Das gleiche gilt auch für Android.

Bedeutet das, wenn Du eine Anwendung für mehrere Plattformen machen möchtest, dass Du das dann xMal parallel entwickelst?

[RWarnecke]

Zitat:

Zitat von Sunec (Beitrag 1279307)

Hattest du für die iOS Entwicklung mit Delphi die Standard-FMX-Komponenten benutzt oder Wrapper, wie beispieslweise: TMS iCL oder DPF

Ich hatte nur die Standardkomponenten von Delphi verwendet.

Zitat:

Zitat von eddie11 (Beitrag 1279308)

Bedeutet das, wenn Du eine Anwendung für mehrere Plattformen machen möchtest, dass Du das dann xMal parallel entwickelst?

xMal neu würde ich jetzt nicht direkt sagen. Aus meiner Sicht ist es ja nur eine Übersetzung in die andere Programmiersprache mit eventuell ein paar kleinen Anpassungen.

[himitsu]

Und Dank der Unterschiede, kann man selbst in Delphi nicht einfach so jeden Code für alle Systeme benutzen/wiederverwenden.
Außer man beschränkt sich auf die nötigsten Gundfunktionen, welche es überall gibt und verzichtet auf so Befehle wie Pos/Copy, AnsiZeugs, PointerZeugs usw.

[mkinzler]

Diese Unterschiede merkt man aber als normaler Programmierer aber normalerweise selten.

[himitsu]

mit 0-Strings oder 1-Strings
mit ARC oder Ohne
mit Weak-References oder nicht
mit AnsiStrings oder ohne

Alles Zeugs, was man hier nahezu überall sieht.

Zugriffe auf einzelne Char im String
Verwendung von Copy und Pos
Objekte in Pointern halten
manchmal auch Kreizreferenzen (Parent kennt Kind und das seinen Parent)

[Daniel]

Es ging nie darum, dass man /jeden/ Code für alle Plattformen nutzen könnte.
Es geht darum, dass man wartbaren Code für alle Plattformen schreiben kann - unter Berücksichtigung von ARC und String-Indexierung.

Ansi-Strings sind ein Relikt, für das es auf den aktuellen Plattformen weniger und weniger Gründe gibt. Und insbesondere die Schnittmenge an Anwendungsfällen, in denen ein Code (a) Ansi-Code verarbeiten muss und (b) auf mobilen Plattformen laufen soll, ist gering. Die meisten Fälle sind konstruiert und nur ein Abbild der Verweigerung vor adäquateren Lösungen.

[Mavarik]

Zitat:

Zitat von Darlo (Beitrag 1276888)

Firemonkey hat sich super entwickelt und 64 bit wirds auch noch schaffen.

Das denke ich auch... btw. können alle iOS devices den 64 bit? - habe mich noch nie damit beschäftigt!