Wiecie, że Apple do duża firma? Dopiero co zapowiedziała szturm na Hollywood, telewizję, banki oraz kioski z gazetami, a już znów miesza w językach programowania. Czyli jednak nadal pamięta, że kiedyś w nazwie za Apple było jeszcze „Computer”.
Wraz z najnowszymi systemami wprowadzono nową wersję Xcode i języka Swift. To jest ważne nie tylko dla programistów. Beneficjentami tej zmiany będą wszyscy użytkownicy systemów Apple.
Swift już dojrzał
W poniedziałek miała premierę oficjalna wersja Xcode 10.2. Obsługuje ona w standardzie nową wersję języka Swift, w którym obecnie jest tworzona zdecydowana większość programów na macOS, iOS, watchOS i tvOS, ale nie tylko.
W ciągu niemal 5 lat Swift rozwijał się bardzo szybko i dynamicznie. Jak widać, doczekał się już pięciu dużych wersji, zaliczając po drodze również ułamki. Dla porównania Objective-C uznawany za standard w Apple od przejęcia NeXT w ciągu 35 lat doczekał się wersji 2.1. Właśnie ta dynamika Swift była jego największą wadą. Deweloperzy musieli sporo czasu poświęcać przy wprowadzaniu kolejnych wersji języka, na zmiany w kodzie. Nad tym udało się zapanować już w okolicach numeru 4.1. Jednak pozostał inny problem który, choć nie bezpośrednio, był dokuczliwy dla każdego użytkownika.
Biblioteki Swift w każdej aplikacji
Języki, nawet niektóre kompilowane jak Objective-C wymagają pewnych bibliotek, z których korzystają aplikacje. Te konieczne dla pracy Obj-C były od lat dołączane do systemu, a to dzięki „stabilności” języka i kompilatorów. Ze Swift tak dobrze być nie mogło. Jak już wiecie, język rozwijał się i programy napisane w nowszych wersjach Swift, wymagały nowszych bibliotek. Z tego powodu były one dołączane do aplikacji, a nie do systemu. Jak się domyślacie, zwiększało to dodatkowo rozmiar każdej aplikacji napisanej w Swift o powielający często kod bibliotek.
Teraz będzie inaczej! Od wersji macOS 10.14.4, iOS 12.2, tvOS 12.2 i watchOS 5.2 biblioteki Swift będą integralną częścią systemów, a aplikacje nie będą musiały ich więcej dźwigać ze sobą. To wszystko dzięki ABI Stability. Obecnie Swift będzie gwarantował zgodność starszych bibliotek podstawowych z nowymi wersjami. Oznacza to, że aplikacje napisane w nowych, przyszłych wersjach Swift, będą działać z podstawowymi bibliotekami zawartymi w systemach udostępnionych wcześniej. Ta stabilność przy okazji zaoszczędzi trochę czasu deweloperom i będą mogli oni pisać lepszy kod.
Swift 5 nagła duża zmiana w numeracji
Jak się domyślacie, po szerszej akceptacji Xcode 10.2 i Swift 5 oraz nowych systemów, aplikacje będą pobierać i instalować się szybciej, zajmą mniej miejsca w naszych urządzeniach i będą stabilniejsze.
Co z innymi systemami? Apple już dawno zaimplementował w Xcode i App Store rozwiązania, które pozwalają na usuwanie z aplikacji zbędnego kodu i danych. Biblioteki będą mogły być przez App Store usuwane z aplikacji, jeżeli sklep rozpozna, że instalacja odbędzie się na nowszym systemie, a dla starszych nadal będą dołączane. Co więcej, jeżeli programista zdecyduje się ustawić zgodność z systemami tylko od obecnych wzwyż, to kompilator nie dołączy bibliotek podstawowych do programu, mając pewność, że znajdują się one w systemie. To jest istotne dla aplikacji dystrybuowanych poza App Store.
Swift 5 przynosi jeszcze wiele innych zmian. Przykładem niech będzie nowa obsługa tekstów w UTF-8, która działa znacznie szybciej.
Interesujące jest to, że Apple zdecydował się wypuścić tak istotną dla programistów zmianę na prawie trzy miesiące przez WWDC wraz z „mniejszymi” aktualizacjami systemów i Xcode. Oznacza to, że na WWDC temat ABI Stability i zgodności podstawowych bibliotek nie będzie najważniejszy. Oj będzie się działo.
Źródło: swift.org https://swift.org/blog/abi-stability-and-more/
Uczę się języka Dart i frameworka Flutter.
Muszę przyznać, że dużo przyjemniej mi się pracuje niż ze Swift’em. A Hot Reload bardzo przyspiesza development.
Dodatkowo mam od razu otwarte drzwi do zarówno do iOS jak i do Androida oraz w przyszłości do Fuksji. Ponoć można też też kompilować do innych ARMów – np. do RPi, ale tego nie testowałem.
Polecam sprawdzić. Szczególnie na YT ciąg filmów Flutter Challenge.
I właśnie przez to mamy tak dużo kiepskich aplikacji na iOS. ZAPAMIĘTAJ: co jest do wszystkiego to jest do niczego!
Tworzenie programów za pomocą uniwersalnych narzędzi to największe ZŁO! To takie „równaj w dół”. I potem mamy dzieła leniwych programistów, którzy koniecznie chcą pisać na wszystko ucząc się jednego, jak mObywatel i inne paskudy bez wsparcia dla podstawowych funkcji systemów Apple.
Nie rób tego, opamiętaj się zawczasu.
Ale sprawdziłeś co potrafi Flutter zanim napisałeś odpowiedź?
Właśnie ten framework jest odpowiedzią na hybrydy typu Ionic / PhoneGap itp., które wymuszały kompromisy.
Polecam zobaczyć jak to działa, może zmienisz zdanie.
Każde tego typu środowisko, generujące na bazie swojego natywnego kodu kod docelowy na konkretną platformę będzie potworkiem. Czy tego chcesz czy nie każda linijka tego pseudo kodu będzie musiała być tak opracowana aby dało się z niej zrobić docelowy kod dla Androida czy iOS a wiec albo będzie nadmiarowa albo będzie w którymś momencie nieelegancka. I mówi Ci to człowiek, który zawodowo zajmuje się programowaniem od blisko 20 lat. Napatrzyłem się przez te wszystkie lata na różne potworki. Nie mówimy tu o tym jak wiele potrafi to środowisko – mówimy o tym ze taka wieloplatformowa realizacja wymaga nadmiarowości albo kompromisów.
Był kiedyś taki wysiwyg-owy edytor html od Mcrosoftu. Polecam poszukać, koniec lat 90-tych. Strony działały w większości ówczesnych przeglądarek. Ale jak się zajrzało do kodu html to chciało się płakać
Niestety również mam wrażenie, że odpisałeś bez sprawdzenia czym Flutter jest. Kompiluje się on bezpośrednio do binarki. Na samym dole jest C++. Bardzo wydajne działa.
Obejrzyjcie sobie co potrafi ten framework i jaką ma wydajność. Bo mam wrażenie, że porównujecie go do czegoś co już znacie i co się nie udało, lub wymagało kompromisów, bez zapoznania się o czym mowa.
Rozumiem, że chcecie pisać natywnie na jedną platformę, Niestety biznes wymaga by aplikacja była wieloplatformowa. I jeśli da się to uzyskać mniejszym kosztem, bez większych kompromisów + utrzymanie będzie tańsze to takie rozwiązanie pewnie wygra.
Tym bardziej, że patrząc jako dev (15 lat) po prostu łatwiej i szybciej się w nim koduje.
C++ nie ma wiele spólnego ze środowiskiem Apple. To naprawdę kiepski język, nawet porównując do ObjC.. Nie chodzi o to do czego się kompiluje, ale o to jakie ograniczenia w dostępie do bibliotek powoduje uniwersalność Twojego kodu,
No cóż. Pytanie tylko czy wszystkie aplikacje potrzebują dostęp do wszystkich bibliotek. Nie mówię, że dany sposób developmentu jest rozwiązaniem na wszystkie bolączki. Pewnie jakiś procent aplikacji musi być napisany w natywnym kodzie. Może przynajmniej część aplikacji. Na pewno teraz dzięki Flutterowi wszystkie aplikacje, które z biznesowych powodów i potrzeb mogły być napisane w rozwiązaniach hybrydowych nie będą – jak to napisałeś – potworkami. Duża część natywnych pewnie też będzie mogła przejść na hybrydę tnąc koszty utrzymania dwóch zespołów deweloperskich. Najlepszym dla mnie tego sygnałem jest to, że Google przepisało wszystkie swoje aplikacje mobilne na Fluttera.
Jako, że starej gwardii i tak nie przekonam to może młodsi programiści zechcą sprawdzić z czym to się je:
Flutter at Mobile World Congress 2019
Dość już tego cięcia kosztów. Przez to nawet banki i rząd wypuszczają na iOS potworki bez Touch i Face ID, nie współpracujące z managerem haseł, do tego ze wstrętnymi zapożyczeniami z interfejsów innych systemów.
To jest naprawdę plaga, którą należī zwalczać, a nie pielęgnować.
Dodałem jeszcze dwie odpowiedzi na Twój komentarz. Dlaczego moderator ich nie przepuścił?