Przejdź do treści
Codivine

Budujemy — aplikacje mobilne

Aplikacje mobilne, z których ludzie naprawdę chcą korzystać.

Aplikacja to poważne zobowiązanie: dwa sklepy, dwa procesy recenzji, użytkownicy na starych telefonach i backend, który musi działać. Warto, gdy telefon naprawdę zmienia to, co możliwe — praca w terenie, tryb offline, powiadomienia, aparat, lokalizacja albo coś, po co ludzie sięgają co tydzień, a nie raz w roku.

Budujemy
  • Wieloplatformowo we Flutterze — jeden kod, oba sklepy
  • Prawdziwy backend, a nie tylko ekrany
  • Powiemy Ci, kiedy lepszą odpowiedzią jest aplikacja webowa

Czy to w ogóle powinna być aplikacja?

Wiele pomysłów przedstawianych jako aplikacje lepiej sprawdzi się jako szybka, responsywna aplikacja webowa. Bez pobierania, bez recenzji w sklepie, jeden kod, natychmiastowe aktualizacje i link, który możesz wysłać każdemu.

Aplikacja broni się wtedy, gdy potrzebuje urządzenia: niezawodnej pracy offline, powiadomień, które faktycznie docierają, aparatu i skanowania, lokalizacji w tle, logowania biometrycznego albo ikony na ekranie głównym, w którą użytkownicy klikają kilka razy w tygodniu.

  • Działa bez internetu i synchronizuje się później — aplikacja
  • Używana co tydzień przez tych samych ludzi — aplikacja
  • Potrzebuje aparatu, GPS-u, Bluetootha albo biometrii — aplikacja
  • Okazjonalne użycie przez osoby, które znalazły Cię w Google — web
  • Treści albo zakupy, które muszą mieć link i być indeksowane — web

Co wbudowujemy w aplikacje

Logowanie

Logowanie mailem, przez media społecznościowe i biometrią, role i uprawnienia, bezpieczna obsługa sesji.

Offline i synchronizacja

Lokalne przechowywanie danych z obsługą konfliktów, żeby aplikacja była użyteczna w piwnicy, magazynie czy na wsi.

Powiadomienia push

Powiadomienia wywoływane przez coś, co realnie dzieje się w Twojej firmie, a nie przez kalendarz marketingowy.

Płatności i subskrypcje

Zakupy w aplikacji, subskrypcje albo zewnętrzne płatności, skonfigurowane tak, by przeszły recenzję w sklepie.

API i backend

Usługa, z którą rozmawia aplikacja — zbudowana przez ten sam zespół, więc umowa między nimi jest spójna.

Analityka i raporty awarii

Wiesz, czego ludzie używają, gdzie odpadają i co się zepsuło na urządzeniu, którego nie masz w ręku.

Od pomysłu do sklepu z aplikacjami

  1. 1Definicja i walidacja
  2. 2Ścieżki i ekrany
  3. 3Budowa
  4. 4Testy na prawdziwych urządzeniach
  5. 5Zgłoszenie do sklepów
  6. 6Publikacja i rozwój

Dlaczego Flutter

Budujemy wieloplatformowo we Flutterze, bo w większości aplikacji biznesowych daje to jeden kod, spójne działanie na obu platformach, dobrą wydajność i rachunek za utrzymanie, który po starcie pozostaje rozsądny.

Tam, gdzie konkretne wymaganie naprawdę potrzebuje kodu natywnego — SDK platformy, integracji ze sprzętem, funkcji systemu — integrujemy go, zamiast udawać, że ograniczenia nie ma. A jeśli Twój projekt byłby naprawdę lepszy w pełni natywnie, powiemy to, zamiast brać zlecenie.

Najczęstsze pytania

iOS, Android czy oba?

W praktyce oba — przy podejściu wieloplatformowym wypuszczenie aplikacji tylko na jedną platformę to dziwna oszczędność. Jeśli Twoi odbiorcy korzystają w przeważającej większości z jednej platformy, możemy zacząć od niej, ale kod od pierwszego dnia obsługuje też drugą.

Ile trwa zrobienie aplikacji?

Konkretna pierwsza wersja z logowaniem, kilkoma kluczowymi ścieżkami i backendem to zwykle od dwóch do czterech miesięcy. Złożoność wynika z integracji, działania offline i liczby różnych ról użytkowników, a dużo mniej z liczby ekranów.

Czy zajmujecie się publikacją w App Store i Google Play?

Tak — konta w sklepach, opisy, zrzuty ekranu, deklaracje prywatności, odpowiedzi na recenzje i zarządzanie wydaniami. Pierwsze zgłoszenia są często odrzucane z drobnych powodów; tę rundę bierzemy na siebie.

Co, gdy Apple albo Google coś zmienią?

Na pewno zmienią. Zmiany zasad sklepów, nowe wersje systemów i wycofywane SDK wymagają okresowego utrzymania, niezależnie od tego, czy dodajesz funkcje. Mówimy o tym otwarcie przy stałej współpracy, zamiast robić z tego niespodziankę.

Zbudujmy aplikację mobilną

Napisz, kto korzystałby z aplikacji i co by w niej robił. Pomożemy ustalić, czy to w ogóle powinna być aplikacja.

Nie potrzebujesz specyfikacji. Opis problemu wystarczy, żeby zacząć.