Python do tworzenia aplikacji mobilnych: Kivy vs BeeWare

Python to wszechstronny język do tworzenia aplikacji mobilnych, a jego narzędzia są dziś lepsze niż jeszcze kilka lat temu.

iOS i Android są oficjalnie wspieranymi platformami dla CPythona, a frameworki takie jak Kivy i BeeWare pozwalają tworzyć aplikacje na oba systemy z jednej bazy kodu w Pythonie.

Koszt tej wygody to wdrożenie: Python nie jest natywny dla żadnej z tych platform, więc do pakowania aplikacji i publikacji w sklepach potrzebujesz kogoś z doświadczeniem.

Dlaczego warto użyć Pythona do tworzenia aplikacji mobilnych?

Python to open source'owy język ogólnego przeznaczenia, więc te same kompetencje, które pozwalają ci budować data pipeline, mogą też posłużyć do stworzenia aplikacji. Kod powstaje szybko, Python dobrze integruje się z rozszerzeniami w C i C++, a pula kandydatów jest na tyle duża, że rekrutacja rzadko opóźnia start projektu.

Najważniejsza korzyść w kontekście mobile to jedna baza kodu dla iOS i Androida. Osobne tworzenie aplikacji oznacza dwie bazy kodu, dwa cykle wydań i dwa zestawy błędów charakterystycznych dla platform.

Sytuacja platformowa się poprawiła. Python 3.13 dodał wsparcie dla iOS w ramach PEP 730 i dla Androida w ramach PEP 738, oba na poziomie Tier 3 of PEP 11, czyli najniższym wspieranym poziomie. Wsparcie na poziomie języka wciąż nie przekłada się jeszcze na dojrzałe narzędzia produkcyjne, więc ryzyko koncentruje się w toolkitach.

Realistycznie wchodzą w grę cztery ścieżki:

Pierwszy wiersz to najkrótsza droga, gdy Python jest podstawowym językiem w firmie, a wartość aplikacji wynika z logiki w Pythonie, a nie z interfejsu.

Jak wybór Pythona wpływa na koszt i harmonogram dostarczenia aplikacji mobilnej?

Wybór języka przesuwa dwie pozycje kosztowe w przeciwnych kierunkach.

Obniża koszty, bo zespół Pythonowy może rozszerzyć pracę na aplikację, zamiast zatrudniać specjalistów od iOS i Androida, a współdzielonej logiki domenowej nie trzeba implementować dwa razy. Silnik wycen, symulacja albo model pipeline powstaje raz i jest przeglądany przez osoby, które za niego odpowiadają, więc nie pojawiają się rozbieżności między dwiema implementacjami ani druga wersja do utrzymania.

Podnosi koszty, bo żaden z tych frameworków nie generuje binarki aplikacji. Briefcase pakuje projekt w Pythonie do projektu Xcode dla iOS i projektu Gradle dla Androida, które twój zespół musi potem zbudować, podpisać i wysłać do sklepów. Publikacja staje się procesem dwuetapowym, który przekracza granicę kompetencji, a tydzień zgłoszenia do sklepu zaczyna zależeć od umiejętności, których zespół Pythonowy zwykle nie ma. Właśnie tu projekty mobile stawiające na Pythona tracą czas w harmonogramie.

Dlaczego warto wybrać Kivy do tworzenia aplikacji mobilnych w Pythonie?

Kivy to framework cross-platform dla Pythona na licencji MIT, działający na Androidzie, iOS, Linuksie, macOS i Windowsie. Obsługuje wielodotyk i działa zarówno na komputerach jednopłytkowych, jak i na telefonach, więc dobrze pasuje do precyzyjnie określonych aplikacji tworzonych z jednej bazy kodu przez mały zespół.

Framework sam renderuje każdy element interfejsu. Jak wynika z jego dokumentacji architektury, Kivy korzysta na wszystkich urządzeniach z OpenGL ES 2.0, a warstwa graficzna jest napisana w C ze względu na wydajność. Widżety są renderowane przez to API graficzne, zamiast odwzorowywać frameworki widżetów danej platformy. Dlatego aplikacja w Kivy wygląda tak samo na telefonie, tablecie i kiosku z Raspberry Pi, ale na żadnym z tych urządzeń nie wygląda natywnie.

To sprawia, że Kivy dobrze nadaje się do paneli operatorskich, kiosków, osadzonych interfejsów dotykowych i narzędzi wewnętrznych, gdzie spójny układ sterowania na różnym sprzęcie ma większe znaczenie niż znajomość wzorców danej platformy. W aplikacji konsumenckiej ta sama cecha staje się wadą, bo aplikacja nie będzie zachowywać się jak inne na telefonie użytkownika.

Z operacyjnego punktu widzenia problemem jest tempo wydań. Historia wydań Kivy w PyPI pokazuje cztery wydania w latach 2023 i 2024 oraz brak stabilnego wydania od wersji 2.3.1 z grudnia 2024 roku. Prace jednak trwają: według stanu na październik 2026 roku kamień milowy 3.0.0 projektu na GitHubie jest ukończony w około 90%, a termin wyznaczono na 1 stycznia 2027 roku. Maintainerzy uznają obecną linię za gotową do użycia produkcyjnego, więc bierzesz na siebie raczej ryzyko zastoju w rozwoju gotowego produktu niż ryzyko pracy na becie.

W przypadku narzędzia wewnętrznego da się to zaakceptować. Jeśli jednak twój plan rozwoju zależy od tego, że framework będzie się rozwijał, staje się to zależnością, której nie da się sensownie wpisać w harmonogram.

Dlaczego wybrać BeeWare do tworzenia aplikacji w Pythonie?

BeeWare podchodzi do interfejsu od przeciwnej strony i rozdziela pracę między elementy pakietu: Toga odpowiada za interfejs, a Briefcase za pakowanie. Cały zestaw jest objęty licencją BSD.

Toga odwzorowuje natywne widżety platformy, więc fonty, przyciski i nawigacja zachowują się tak, jak użytkownicy oczekują na danym urządzeniu. Użytkowników końcowych nie obchodzi, w jakim języku powstała aplikacja, ale zauważają, gdy pole tekstowe działa inaczej niż każde inne pole tekstowe na ich telefonie. Dlatego Toga lepiej pasuje do aplikacji skierowanych do klientów, które muszą sprawiać wrażenie naturalnie osadzonych na danym urządzeniu.

Słabym punktem BeeWare jest dojrzałość. Zarówno Toga, jak i Briefcase mają w PyPI klasyfikację „Development Status 4 - Beta” i wciąż pozostają poniżej wersji 1.0, więc między wydaniami trzeba liczyć się ze zmianami API. Z drugiej strony nowe wersje pojawiają się często: Toga 0.5.7 wydano 1 października 2026 roku, a Briefcase 0.4.6 13 października 2026 roku.

Kivy vs BeeWare: na czym budować?

Żaden z tych frameworków nie jest lepszy w każdej sytuacji; decyduje typ aplikacji, którą tworzysz. Wybierz Kivy, gdy wymagasz spójnego interfejsu na różnych urządzeniach, a tempo wydań frameworka nie blokuje twojego planu rozwoju. Wybierz BeeWare, gdy liczy się natywne zachowanie, a zespół jest w stanie poradzić sobie z częstymi zmianami zależności.

Oba opierają się na standardowym argumencie za rozwojem cross-platform z jedną bazą kodu, ale żadne nie jest bezpośrednim odpowiednikiem Fluttera ani React Native w aplikacji konsumenckiej. Traktowanie ich w ten sposób właśnie tu prowadzi do problemów.

Czy warto stworzyć aplikację mobilną w Pythonie?

Tylko wtedy, gdy wartość aplikacji wynika z logiki w Pythonie, którą już masz. W przypadku konsumenckich aplikacji mobilnych ocenianych pod kątem jakości interfejsu bezpieczniejszym wyborem są Flutter i React Native: mają większe pule talentów, dojrzalsze narzędzia do publikacji w sklepach i jakość interfejsu, której Kivy nie dorównuje, a Toga dopiero do niej zmierza. Wybór Pythona w takim przypadku oznacza wolniejszą drogę bez żadnej komercyjnej korzyści.

W przypadku mobilnego front endu dla istniejącej logiki w Pythonie kalkulacja wygląda inaczej. Aplikacje naukowe i inżynierskie, panele sterujące sprzętem, wewnętrzne narzędzia operacyjne i interfejsy aparatury pomiarowej zyskują na tym, że cały stos opiera się na jednym języku, a żadna z nich nie konkuruje pod względem dopracowania z aplikacjami konsumenckimi.

Często lepszym rozwiązaniem jest Python za interfejsem, a nie w nim. Na przykład w platformie zakupowej dla hoteli Avisio siedmioosobowy zespół Monterail dostarczył MVP w cztery miesiące, wykorzystując backend w Pythonie i Django oraz webowy front end w React. Ten sam podział sprawdza się w mobile: zespół Pythonowy odpowiada za logikę, a klient natywny albo cross-platform z niej korzysta.

Co musi się zgadzać, zanim opublikujesz aplikację w Pythonie w App Store i Google Play?

O tym, czy mobilny build w Pythonie trafi do sklepów zgodnie z harmonogramem, decydują trzy rzeczy.

Co Briefcase zostawia po stronie twojego zespołu?

Briefcase daje ci projekt Xcode i projekt Gradle. Jego przewodniki po podpisywaniu kodu obejmują Androida, Linuksa, macOS i Windows, ale nie iOS, więc profile provisioningu, metadane sklepu i odpowiedzi w procesie review nadal pozostają pracą natywnego zespołu mobile.

Drugą luką są zależności. Pakiety napisane wyłącznie w Pythonie przechodzą bez problemu, ale wszystko, co zawiera rozszerzenie w C, wymaga wheela zbudowanego dla platformy mobilnej. Jeśli nikt go nie opublikował, problem przechodzi na twój zespół.

Jak dołączenie runtime'u Pythona wpływa na aplikację?

PEP 738 opisuje artefakt dla Androida jako „zestaw skompilowanych bibliotek, które programiści mogą dodać do swoich aplikacji”. W praktyce każda aplikacja w Pythonie zawiera własny interpreter, a rozmiar binarki rośnie wraz z drzewem zależności. Przetestuj ją na najstarszym urządzeniu, które chcesz wspierać, zanim zamkniesz listę zależności.

Kto akceptuje interfejs i plan wyjścia awaryjnego?

Uzgodnij oczekiwania dotyczące interfejsu z interesariuszami zanim zacznie się projektowanie, bo efekt Kivy nie będzie wyglądał natywnie i żaden styling tego nie zmieni. Potem wyceń plan wyjścia: jeśli rozwój toolkitu utknie, trzeba przepisać każdy ekran i zbudować pipeline publikacji od nowa.

Jak zespoły podejmują dobrą decyzję w sprawie Python mobile?

Porównanie frameworków zostaw na koniec. Zespoły, które skutecznie dostarczają aplikacje mobilne w Pythonie, zaczynają od pytania, gdzie leży wartość aplikacji. Jeśli daje ją logika w Pythonie, której ponowne zaimplementowanie byłoby kosztowne i podatne na błędy, utrzymanie jednego języka w całym stosie rekompensuje narzut związany z pakowaniem. Jeśli wartość leży w interfejsie, ten narzut niczego nie daje, a projekt konkuruje z narzędziami zbudowanymi specjalnie do tego zadania.

Drugie pytanie dotyczy tego, kto odpowiada za natywny pipeline, bo od tego zależy, czy w ogóle masz datę publikacji. Odpowiedz na oba pytania, zanim zaczniesz porównywać tabele funkcji, a wybór frameworka stanie się małą decyzją, a nie czymś, od czego zależy powodzenie całego projektu. Jeśli chcesz sprawdzić, gdzie powinna kończyć się twoja baza kodu w Pythonie, a zaczynać klient natywny albo cross-platform, nasi inżynierowie Pythona i mobile mogą przejść z tobą przez architekturę.