[Fmx, iOS, Rx1022]Wird iOS32 noch benötigt ?

[Rollo62]

Hallo zusammen,

ich beschäftige mich gerade mit dem Abspecken und einer ganz neuen, jungfräulichen Installation, ohne Ballast.

Es gab/gibt für iOS die Option "Generate iOS universal binary file (Armv7 + Arm64)",
mit dem 32+64Bit Binraries erzeugt werden können.

So wie ich das verstanden habe, ist Apple mittlerweile auf iOS64 umgestellt, und
nur noch alte AppStore Apps können 32+64 Bit sein, neue Apps MÜSSEN 64-Bit sein.´

Ist das so korrekt ?

Falls ja, wäre dann bei neuen Projekten denn noch das iOS32 Bit SDK überhaupt nötig ?
Ich werde mal versuchen das wegzulassen, und evtl. bei Bedarf anzulegen.

Hat das schon jemand so gemacht (reine 64-Bit im Store), und auf welchen Geräten läuft es dann noch ?

Rollo

[Sherlock]

Gegenwärtig kommst Du ohne iOS32 nicht auf den Simulator.

Sherlock

[Rollo62]

Mit Simulator mache ich schon seit Seattle oder Berline nichts mehr.
Das entspricht leider nicht wirklich der echten Hardware, und kann ich nur für grobe UI Ansichten gebrauchen.

Geht der denn überhaupt wieder mit iOS11, soweit ich weiss ist der doch noch nicht freigegeben ?

Rollo

[mensch72]

Alleine wegen Entwicklung und Test per/mit IPhone5 und weit verbreiteten IPad4 und sei es nur als internes Deploy, ist IOS-32Bit weiter nötig.

Telefone werden schneller gewechselt wie iPads, daher erben die Entwickler dann oft die "alten" IPhones:)

[Sherlock]

Der Simulator ist auch als iOS 10 Maschine ansprechbar. Und ist deutlich besser zu debuggen, als ein echtes Gerät. Am Simulator sehe ich immerhin noch Objektinhalte im Quellcode und kann ordentlich durchsteppen, am Gerät...nada.

Sherlock

[Rollo62]

Zitat:

daher erben die Entwickler dann oft die "alten" IPhones

Stimmt, da kann ich nur zustimmen.
Aber mittlerweile "erbe" ich iPhone6 etc.
Das Thema iOS32 wird eigentlich schon erledigt sein.

Mit den alten Schätzchen möchte ich auch gar nicht mehr entwicklen, aber es stimmt das iOS32 stabiler erscheint als 64-Bit, und besser zu debuggen.
Aber das ist marginal.

Es hängt doch eher an dem AppStore, was der überhaupt noch durchlässt.

Ich vermute mal es gibt keinen Unterschied ob AppStore oder AdHoc, da wird bei Beidem in Richtung 64-Bit geschossen.

Woran kann ich denn die Geräte ausmachen die mit NUR 64-Bit nicht mehr unterstützt werden ?
(am Gerät <= iPhone 5, am installierten OS <= iOS9/10, oder was sonst) ?
Mal abgesehen von den Hardware-Features.

Zitat:

Und ist deutlich besser zu debuggen, als ein echtes Gerät.

Das habe ich daran auch sehr geschätzt.
Aber es kann fast nichts was ein echtes Gerät kann, oder vielleicht nur mit jeder Menge "Nacharbeit", und dann ist mann nie sicher ob es im echten Gerät auch so funktioniert.
Wie gesagt, reines UI ist sinvoll mit dem Simulator, an echter Hardware kommt man aber nicht vorbei.

Rollo

[mensch72]

..."Woran kann ich denn die Geräte ausmachen die mit NUR 64-Bit nicht mehr unterstützt werden ?"...

Unser Ansatz:
- alles wofür es kein IOS11 gibt, definieren wir als 32Bit und geben Support für neu Projekte nur noch auf Einzelanfrage(gegen Geld bis zur Einzelgeräteaktivierung in irgendeinem DevAccount zur Direkt-Installation auch ohne Appstore)
- alles wofür es IOS11 gibt, definieren wir als 64Bit und wird im Rahmen der technischen Möglichkeiten aktuell voll unterstützt

[Rollo62]

Zitat:

gegen Geld bis zur Einzelgeräteaktivierung in

Das würd ich mir aber sparen, die Verantwortung liegt doch klar bei Apple.
Wieviel soll der Kunde denn für solch einen Luxus bezahlen ?
Dafür bekommt er doch auch ein neueres iPhone.

Wenn du diese "Sonderanfertigng" für teuer Geld anbietest wird der Kunde am Ende dich zur Verantwortung ziehen wollen wenn etwas nicht mehr funktioniert.
Das wäre mir ein etwas zu heisses Eisen, schliesslich kan Apple wieder jederzeit was Irrsinniges aus dem Hut zaubern.

Die Definition ab iOS-11 ist wohl korrekt.
Aber die Frage ist sollte man noch 32+64 Combined Apps hochladen, weil evtl. nicht Alle das Update mitmachen ?
Das wird sich wohl ziemlich in der Binary-Größe bemerkbar machen.

Ich weiss das es bei Apple viel üblicher bei den Kunden ist Alles mitzumachen, deshalb wird der 32-Bit Status wohl nicht mehr lange vorhanden sein müssen.

Rollo

[mensch72]

..."Wieviel soll der Kunde denn für solch einen Luxus bezahlen ?"
..."Wenn du diese "Sonderanfertigng" für teuer Geld anbietest wird der Kunde am Ende dich zur Verantwortung ziehen wollen wenn etwas nicht mehr funktioniert."...

Das sehe ich zufällig genau andersherum und fahre damit im Bereich von Finanz&Service so sehr gut und sogar incl. Planungssicherheit.
Was kostet es den Kunden? ...die Gebühr einer dafür eigenen AppleDevID... und wenn ich es als Dienstleistung machen oder einrichten soll noch etwas "Aufwandsentschädigung". (bis zu 100 IOS Geräte des Kunden kann er/ich dann so per UUID so registrieren und frei mit dafür signierten DevApps versorgen...)

IPhone5 und IPad4 laufen und bleiben seitens Apple mit IOS10.x nun 100% stabil, weil Apple selbst dafür ja nun nix mehr aktualisiert:)
Das ist mir so wesentlich lieber wie ein aktuelles IOS11 mit Systemupdates im 2Monatstakt.

Und so sind derzeit alle glücklich... bis zu 100 32Bit-IOS Geräte können so für wenig Aufwand weiter mit aktuellen&neuen Apps versorgt werden, weil ohne AppStore wenn es drauf ankommt sogar sehr schnell. Aber du hast Recht: Ich bin einer der wenigen die das optional so anbieten, fast alle sonstigen Anbieter halten sich strikt an Apple und haben IOS10/32Bit nunmehr aus ihrem Angebot&Support gestrichen... Ich finde das gut, so bekomme ich teils mal einen Fuß in eine Tür die normalerweise für mich verschlossen wäre.
Aber solche Kunden registrieren teils auch ihre aktuellen Geräte in so einem DevID-Account, weil ich ihnen darüber zeitnahe unmittelbare App-Updates und Testversionen bieten kann, teils mit Features welche wir so nicht durch die AppStore Prüfung bekommen würden;)

[Rollo62]

Das ist sehr schön für dich wenn das so läuft :thumb:

Ich vermute mal das liegt an

Zitat:

Bereich von Finanz&Service

da ist halt mehr Geld im Umlauf, für die sind das Peanuts.

In der restlichen Consumer-Welt gilt leider "Geiz ist Geil",
und Kunden die für 100 EUR Kaufen erwarten i.d.R. für 1000 EUR kostenlosen Service :stupid:

Kann man den noch per AdHoc-Verteilung steuern ob 32/64-Bit erlaubt sind,
oder hat das Apple auch rausgeworfen und will rigoros nur noch 64-Bit ?

Rollo

[mensch72]

Per Adhoc gehen definitv CombiApp's(also 64+32Bit), aber das mit den IPAs ist nicht meine primäre Spielwiese, denn für echtes Deploy bin ich nicht zuständig.

Bei mir läuft das eher so:

https://www.flexihub.com
1. Kunde installiert sich per Flexihub einen Remote-USB-Treiber, schließt sein "Problem/Neu-IOS-Device" an seinen Computer an und gibt den USB-Port für Remotezugriff frei, bzw. startet TeamViewer das ich dies Remote fix selbst mache.
2. Ich starte die OSX-VM wo ein PAserver und ein XCode mit der DevID des Kunden konfiguriert ist
3. ich verbinde meinen PC und letztendlich die OSx-VM über Internet mit dem über Flexihub freigegebenen USB-Port des Kunden(dafür benötige "nur ich" eine bezahlte Flexihub Lizenz)
4. Ich starte Xcode mit einer MiniApp, um kurz zu sehen ob das IOS-Device im Account voll registriert ist und man eine App (remote) dort installiert bekommt (XCode meckert wenn was nicht stimmt und bietet zu 99% auch gleich die Lösung, wie z.B. Gerät auf DevID registrieren)
5. Ich starte den PAserver
6. Ich starte in einer anderen VM ein passendes Delphi und schiebe je nach Bedarf eine 32Bit oder 64Bit direkt auf das Gerät, bzw. kann wenn es denn sein muss und wenn die INet-Verbindung gut ist sogar remote Debuggen

Das dauert wenn die VMs einmal vorbereitet sind so pro Zusatzfall dann oft nur 10..15min und wird bei zusätzlichen Erstinstallationen oder "schnellen" Sonderwünschen / Problemen im Einzelfall von den Kunden gerne bezahlt (bzw. zumindest so akzeptiert).

Ab dann ist nebenbei ja auch die DeviceUDID im DevAccount des Kunden und in seinen Zertifikaten automatisch registriert, sodass später auch das Spiel mit den ADHOC IPAs klappt, um mal fix ein Deploy für alle zu machen, was die dann einfach per Link installieren können.(wie das genau abläuft hat mich bisher nicht interessiert, ich weiß nur wenn ein IOS-Gerät so "vorbereitet ist", klappt dann auch das ADHOC:) )

[Rollo62]

Ja das ist mal ein cooles Setup :thumb:

Darauf das man per Remote USB so stabil arbeiten kann hätte ich jetzt nicht gewettet :stupid:

Wie waren da noch die Konditionen ?
- du kannst bis zu 100 Devices an eine Lizenz binden, als Developer, richtig ?
- per AdHoc waren es glaube ich auch 100 Devices, aber du brauchst das ja gar nicht.

Clever gemacht um dieses bescheuerte AdHoc zu Vermeiden.

Hast du dich auch mal mit CloudServices zur Test-Distribution beschäftigt ?
https://testfairy.com/#distribution
https://blog.playtestcloud.com/testf...s-ios-android/

Hatte mich mal mit TestFairy und HockeyApp beschäftigt.
Die solten das irgendwie hinbekommen, hatte mir das vor einiger Zeit mal angesehen, aber dann nicht weiter damit getestet.

Rollo

[mensch72]

..."Darauf das man per Remote USB so stabil arbeiten kann hätte ich jetzt nicht gewettet"...

Weil ich eh nur noch per VMs arbeite, kam irgendwann die nahe liegende Frage ob das nicht auch Rechner übergreifend geht.

Also habe ich meine VMs mal von VMwareWorkstaion/Fusion auf/für einen VMwareESXi Server angepasst&übertragen... SchauEinerGuck, das funktionierte weil wenn man per VMwareWorkstaion die nun "externe ausgeführte VM" nutzte, waren alle lokalen USB-Devices auch in der real auf dem ESXi ausgeführten VM verfügbar... also praktisch ein "USBoverIP".
Dann einfach bei Google mal "USBoverIP" oder "USBoverEthernet" eingegeben und schon gab es das passende. Ich finde wie bei Teamviewer die Lösung das nur ich selbst einmal zahle und damit dann "eine" Verbindung zu aber beliebig vielen externen USB-Freigaben aufbauen kann hierfür geradezu "ideal":)

[mensch72]

..."Hast du dich auch mal mit CloudServices zur Test-Distribution beschäftigt ?"...
Nein, gehört nicht zu meiner Spielwiese.

Ich weiß nur das wir mal was "TestFlight" verteilt hatten. Da ging aber bestimmtes nicht oder nicht schnell genug, weshalb ich selbst mich aktuell auf den Direkttest bzw. die Direktauslieferung spezialisiert habe.

Erst bei Updates für über 25 Geräte denkt unser Deploy eventuell über eine spezielle ADHOC-Version per InstallLink für "alle" nach.
Bei allem darunter bekommen die AppNutzer von Kunden mit ServiceVertrag wenn sie mal online sind einen Hinweis, das es ein Update gibt und sie sich "bei Gelegenheit" mal melden sollen, um einen Installationstermin zu vereinbaren... das wird dann von irgendwem im Alltagsgeschäft mit nebenbei erledigt.

Ich selbst bekomme selbst im Prinzip nur Neuprojekte, Problemfälle oder spendable Kunden mit "sofort"Sonderwünschen direkt zugeteilt.

[Rollo62]

TestFlight benutze ich nur zum Testen an interne Mitarbeiter.
Das hatte so seine Schwierigkeiten, aber im Moment geht es ganz gut.
Um Neue Mitarbeiter einzuladen muss man die üblichen Apple-Verrenkungen machen, und es geht bei mir nicht immer.

Deshalb hatte ich nach einer einfacheren Alternative gesucht, am Besten Android+Ios.

Was ich z.B. bei C# sehr schön find ist den Xamarin-LivePlayer, sowie ich das sehe kommt der FMX LiveUI da nicht dran.
Hab da noch nicht so tief reingeschaut wie das gemacht wird, aber das geht womöglich nur weil C# ein Interpreter ist, d.h. bei Delphi wird sowas schwierig.

Ich frage mich nur wie das erlaubt sein kann, denn Apple verbietet das Unterschieben von "Script-Code" soweit ich weiss, das war dioch der Grund warum die Flash verbannt hatten.

Rollo

[Rollo62]

Du kannst die Marke von 25 vielleicht auf 75 bis 150 oder mehr hochsetzen.
https://stackoverflow.com/questions/...-limit-is-over
http://appleinsider.com/articles/13/...eloper-account

Aber Apple hält sich damit wohl etwas bedeckt.
https://help.apple.com/xcode/mac/current/#/dev7ccaf4d3c
https://developer.apple.com/support/account/
Hier steht 100 devices, andere iOS Developer s.o. schreiben schon etwas von 200 Devices.

Es bleibt halt immer etwas Mysteriös :stupid:

Rollo

[mensch72]

..."Du kannst die Marke von 25 vielleicht auf 75 bis 150 oder mehr hochsetzen."...
(es gehen immer 100Devices, mit einer BusinessDevID wohl sogar noch etwas mehr)

Unsere 25er Entscheidungsschwelle ist unser purer Zeitaufwand den es dauert ~25Geräte so mit Einzelupdate a ~10min zu versorgen... so in 4..5h Arbeitszeit bekommt man auch eine getestete ADHOC Variante wohl sauber hin. (100Geräte per Einzelupdate wären mehr als 16h Fulltime, selbst wenn das bezahlt würde, wäre es schade um die Arbeitszeit)