Własne SDK: jak udostępnić swoją usługę w aplikacjach partnerów

Czym jest SDK i gdzie kończy się API

SDK (ang. software development kit, zestaw narzędzi programistycznych) to gotowy pakiet kodu, modeli danych, konfiguracji, dokumentacji i przykładów, który pozwala programiście osadzić cudzą usługę we własnej aplikacji bez znajomości jej wewnętrznej budowy.

Właściciel produktu (ang. product owner) w zespole aplikacji mobilnej ma z tym styczność codziennie, zwykle z drugiej strony. Analityka i powiadomienia push wchodzą przez bibliotekę Firebase. Mapę rysuje komponent dostawcy map. Czat wsparcia, sieć reklamowa, raportowanie awarii, logowanie kontem Google czy Apple – wszystko to trafia do aplikacji jako obca paczka, którą ktoś inny rozwija i za którą ktoś inny odpowiada.

Nazwy tych warstw bywają używane zamiennie, choć różnią się one tym, ile pracy zostaje po stronie integratora.

Wartość SDK bierze się z tego, co ono ukrywa. Partner nie musi rozumieć, jak wygląda protokół komunikacji z Twoim urządzeniem, w jakiej kolejności trzeba potwierdzić zgody przed obciążeniem karty ani co zrobić, gdy użytkownik wróci po ośmiu minutach spędzonych w aplikacji banku. Odpowiedzialność za poprawność tych rzeczy przenosi się na dostawcę.

Czego nie załatwi samo REST API

Najłatwiej to zobaczyć na funkcjach, których nie da się dostarczyć jako zestaw wywołań serwerowych, bo wymagają kodu żyjącego wewnątrz cudzego procesu.

Odroczony link głęboki – kontekst, który musi przetrwać instalację

Link głęboki (ang. deep link) prowadzi do konkretnego ekranu w zainstalowanej aplikacji. Odroczony link głęboki (ang. deferred deep link) ma zrobić to samo wtedy, gdy aplikacji jeszcze nie ma: użytkownik klika reklamę konkretnego produktu, trafia do sklepu z aplikacjami, instaluje, uruchamia – i powinien wylądować na karcie tego produktu, a nie na ekranie startowym.

Na Androidzie pomaga w tym systemowy mechanizm przekazywania parametrów instalacji – Play Install Referrer, który przekazuje aplikacji adres kierujący do instalacji wraz ze znacznikami czasu kliknięcia i instalacji. Na iOS takiego odpowiednika nie ma, a kolejne wersje systemu zawężały obejścia: dostęp do schowka wymaga dziś zgody użytkownika, a rozpoznawanie urządzeń po ich cechach technicznych jest przez Apple zabronione. Lukę wypełniają wyspecjalizowane biblioteki atrybucyjne, czyli takie, które przypisują instalację do źródła reklamy: AppsFlyer, Branch i podobne. Opierają się na dopasowaniu probabilistycznym o niepełnej skuteczności. Takie SDK zbiera w jednym miejscu wszystkie dozwolone sposoby obejścia tego ograniczenia i pilnuje ich aktualności przy kolejnych wersjach systemu. Tego żaden partner nie zrobi sam w rozsądnym czasie.

Raportowanie awarii, czyli kod startujący przed Twoim

Biblioteka monitorująca stabilność aplikacji, na przykład Sentry, przechwytuje awarie natywne, zawieszenia interfejsu oraz wyłączenia aplikacji przez systemowy mechanizm nadzoru. Żeby to działało, musi zostać uruchomiona przed kodem aplikacji – dokumentacja iOS zaleca inicjalizację „na wątku głównym tak wcześnie, jak to możliwe", bo tylko wtedy wykrywanie awarii przy starcie jest wiarygodne.

Serwer nie zobaczy zdarzenia, którego aplikacja nie zdążyła zaraportować, zanim się zamknęła.

Co się dzieje, gdy płatność wychodzi poza aplikację

Zapłata w aplikacji sklepu to sekwencja, w której użytkownik wychodzi do portfela systemowego albo do aplikacji banku i wraca nie wiadomo kiedy: raz po wygaszeniu ekranu, raz po ubiciu aplikacji przez system. Do tego dochodzą ekrany zgód, opłata doliczana konsumentowi za wybraną metodę płatności, obsługa wyniku uwierzytelnienia i stan transakcji, który trzeba odtworzyć po powrocie.

Apple Pay i Google Pay w ogóle nie są dostępne inaczej niż przez natywne komponenty systemowe. Podobnie jest z terminalem płatniczym w samym telefonie: Apple udostępniło Tap to Pay na iPhonie w Polsce 18 marca 2025 roku, a korzystać z niego można wyłącznie przez aplikacje dostawców usług płatniczych – wystarczy iPhone i aplikacja partnerska, bez dodatkowego terminala. Dostęp do tej funkcji jest więc dystrybuowany przez cudze SDK i nie da się go opakować po stronie serwera.

Kiedy własne SDK ma sens

Zapytaj wprost: czy bez SDK każdy partner musiałby samodzielnie rozwiązać ten sam trudny problem? Jeśli tak, biblioteka ma szansę zwrócić się na samym skróceniu wdrożeń i spadku liczby zgłoszeń do wsparcia.

Im więcej tych sygnałów występuje naraz, tym mocniejsza podstawa. Jeden sygnał to za mało na produkt.

Kiedy wystarczy API i wygenerowany klient

Przy prostych operacjach (pobranie katalogu, wysłanie formularza, wygenerowanie raportu, odczyt konfiguracji) biblioteka nie dokłada niczego ponad to, co narzędzia potrafią wygenerować automatycznie. OpenAPI Generator wystawia dziś 89 generatorów klientów, w tym dla Swifta, Kotlina, Javy i Darta. Ręczne opakowanie kilkunastu adresów w klasy zajmuje dzień i nie wymaga osobnego zespołu.

Własne SDK bywa złą decyzją także wtedy, gdy integratorzy pracują w wielu różnych technologiach, gdy funkcjonalność zmienia się co miesiąc, gdy usługa w ogóle nie sięga do możliwości telefonu albo gdy w firmie nie ma nikogo, kto weźmie bibliotekę na własność na kilka lat. W takich warunkach dobrze udokumentowane API plus wygenerowany klient plus przykładowa integracja dowożą większość korzyści przy ułamku kosztu.

Jak to wygląda w praktyce

Norbsoft rozwija dedykowane SDK dla klientów w dwóch bardzo różnych odmianach: bibliotek opakowujących komunikację ze sprzętem oraz bibliotek płatniczych. Różnica między nimi pokazuje, że „SDK" bywa nazwą dla całkiem różnych problemów inżynierskich.

Czujnik koloru – matematyka kalibracji schowana za API

Nix Sensor Ltd produkuje kolorymetry: urządzenia, które mierzą kolor powierzchni i podają wynik w przestrzeniach barw używanych w druku, kosmetyce czy budownictwie. Firma potrzebowała, żeby jej sprzęt dało się obsłużyć z aplikacji tworzonych przez podmioty trzecie na iOS i Androida.

Norbsoft zrealizował zlecenie o zakresie typowym dla takiej biblioteki. Kod obsługi sprzętu i matematyka kalibracji miały zostać ukryte wewnątrz API. Biblioteka miała być modułowa i zgodna ze standardami obu platform, prosta w użyciu dla zewnętrznych zespołów i przygotowana na kolejne aktualizacje sprzętu. Cały nacisk położono na rdzeń: interfejs do sprzętu oraz przeliczenia barw.

Nix rozwija dziś własne SDK samodzielnie i dobrze widać, dokąd taki produkt zmierza. Nix Universal SDK obsługuje iOS, Androida, macOS, Windows i Linux, łączy się z urządzeniami przez USB oraz BLE (ang. Bluetooth Low Energy, energooszczędny Bluetooth), dostarcza funkcje konwersji i porównywania barw, a w pakiecie idzie w pełni działająca aplikacja demonstracyjna z kodem źródłowym. Produkt, który startował jako jeden rdzeń na dwie platformy, po latach obsługuje pięć systemów i całą linię urządzeń.

Sterowniki chłodziarek, czyli protokół BLE ukryty w cudzym narzędziu

Elstat Electronics produkuje sterowniki Nexo montowane w chłodziarkach, które producenci napojów ustawiają w sklepach. Sterownik zbiera dane o pracy urządzenia, otwarciach drzwi i temperaturach; aplikacja mobilna łączy się z nim bezprzewodowo, gdy przedstawiciel handlowy znajdzie się w pobliżu, i przekazuje odczyty do chmury. Na tej podstawie działa monitoring stanu floty, analiza ruchu przy lodówce i wyłapywanie sprzętu przestawionego w nieuzgodnione miejsca.

Norbsoft opracował dla Elstatu SDK opakowujące komunikację BLE ze sterownikami: wykrycie urządzenia, odczyt i ustawianie parametrów, przesyłanie zebranych danych do chmury. Biblioteka mogła zostać osadzona w narzędziach biznesowych innych firm – na przykład w aplikacjach terenowych dużych rozlewni napojów, które mają w sklepach tysiące takich urządzeń.

To, co widać na ekranie jako jeden przycisk, w warstwie protokołu jest wieloetapową transakcją. Żeby wycofać sterownik z eksploatacji, trzeba kolejno domknąć ostatnią synchronizację, przywrócić ustawienia fabryczne, usunąć identyfikator zasobu i dopiero wtedy potwierdzić operację. Przerwanie w środku – bo handlowiec odszedł od lodówki albo padł mu telefon – zostawia urządzenie w stanie pośrednim.

Widok połączonego sterownika (z lewej): identyfikator zasobu, wersje oprogramowania układowego, numer seryjny, siła sygnału oraz operacje serwisowe. Wycofanie urządzenia (z prawej) rozpisane na cztery etapy – każda taka operacja to osobna sekwencja poleceń po BLE, a odtwarzanie jej po stronie każdego integratora osobno jest źródłem błędów, których dostawca sprzętu nigdy nie zobaczy. Aplikacja Nexo dla Elstat Electronics (Norbsoft).

Taki wielokrokowy protokół uzasadnia bibliotekę. Integrator dostaje jedno wywołanie i jednoznaczny wynik; obsługa ponowień, przerwań i stanów pośrednich zostaje u dostawcy, który jako jedyny zna zachowanie własnego sprzętu. Kompetencje w tym obszarze opisujemy szerzej przy komunikacji z urządzeniami i IoT oraz w segmencie urządzeń dedykowanych.

Logowanie, tryb serwisowy i lista wykrytych urządzeń z siłą sygnału. Skanowanie otoczenia, kolejkowanie połączeń i rozróżnianie stanów synchronizacji to typowa zawartość SDK sprzętowego. Aplikacja Nexo dla Elstat Electronics (Norbsoft).

Bramka płatnicza – cały proces zakupu wewnątrz aplikacji partnera

Autopay S.A. (dawniej Blue Media), polska spółka technologiczno-finansowa dostarczająca usługi płatnicze firmom, zgłosiła się z potrzebą kompleksowej przebudowy swojego SDK płatności mobilnych na iOS i Androida. Celem było zbudowanie biblioteki od nowa, na aktualnych standardach obu platform, wraz z odświeżeniem warstwy wizualnej.

W 2025 roku użytkownicy BLIK-a wykonali 2,9 mld transakcji o wartości 441,5 mld zł, z czego 704,5 mln operacji przypadło na płatności w sklepach stacjonarnych; na koniec grudnia system obsługiwał 20,7 mln aktywnych kont. Każda aplikacja handlowa, która chce przyjmować te płatności, potrzebuje kogoś, kto utrzyma warstwę integracyjną za nią.

Prace zaczęły się od analizy wymagań biznesowych i przeglądu kodu istniejącego SDK, równolegle z rozpoznaniem aktualnych standardów platform. Rezultatem jest architektura rozdzielająca logikę biznesową, komunikację z API i warstwę prezentacji. Przekłada się to bezpośrednio na sposób integracji: partner może użyć gotowych ekranów, wziąć tylko wybrane komponenty albo zbudować własny interfejs na udostępnionej logice domenowej. Lista metod płatności generowana jest dynamicznie na podstawie danych z API, więc nowy kanał wchodzi bez zmian w aplikacjach partnerów. Tak samo obsłużono zgody formalne i opłaty doliczane konsumentowi – pobierane z serwera i sterowane konfiguracją. Dzięki temu zmiana regulacyjna nie wymaga nowej wersji biblioteki.

Gotowy natywny ekran wyboru metody płatności dostarczany przez SDK Autopay (Norbsoft). Partner może go użyć bez zmian albo zastąpić własnym – logika pod spodem zostaje ta sama.

Biblioteka powstała natywnie na obu platformach: Swift i SwiftUI na iOS, Kotlin i Jetpack Compose na Androidzie, bez warstw pośrednich i z zachowaniem kompatybilności wstecznej z projektami działającymi już na produkcji. Przygotowano też warianty paczki, między innymi z modułem OCR (ang. optical character recognition, optyczne rozpoznawanie znaków) i bez niego, żeby integrator nie płacił rozmiarem aplikacji za funkcję, której nie używa. Interfejs zaprojektowano zgodnie z WCAG (ang. Web Content Accessibility Guidelines, wytyczne dostępności treści internetowych). Dla aplikacji finansowych przestało to być kwestią dobrej woli – piszemy o tym w tekście o dostępności aplikacji mobilnych i European Accessibility Act.

Dla bramki transferuj.pl, działającej dziś pod marką Tpay, Norbsoft przygotował wersję SDK płatności na iOS. Tpay publikuje obecnie cztery biblioteki mobilne – na Androida, iOS, Fluttera i React Native. Jedna decyzja produktowa oznacza więc cztery utrzymywane produkty, każdy z własnym cyklem wydawniczym.

Granica między SDK a backendem

Najczęstszy błąd architektoniczny w projektach SDK to źle poprowadzona granica odpowiedzialności. W bibliotece ląduje to, co musi wykonać się na urządzeniu; na serwerze zostaje to, co musi być kontrolowane centralnie albo zmieniać się bez aktualizacji cudzych aplikacji.

Dwie rzeczy nigdy nie trafiają do biblioteki: poufne klucze i dane uwierzytelniające (tzw. sekrety) oraz reguły, których naruszenie kosztuje pieniądze. Paczka aplikacji jest dostępna dla każdego, kto ją pobierze, więc klucz prywatny umieszczony w SDK należy traktować jako klucz opublikowany. Podobnie z limitami, prowizjami i warunkami akceptacji operacji: regułę sprawdzaną wyłącznie na urządzeniu da się obejść podmienionym klientem.

Praktyczny test tej granicy: czy jesteś w stanie zmienić zachowanie usługi u wszystkich partnerów w ciągu doby? Jeśli odpowiedź brzmi „tylko po wydaniu nowej wersji i po tym, jak każdy partner ją wdroży", to reguła siedzi w złym miejscu. Zasady bezpiecznego projektowania aplikacji finansowych opisujemy przy warstwie bezpieczeństwa.

Gotowe ekrany czy sam silnik

Dostawcy SDK dzielą się na dwie szkoły. Jedna dostarcza zamknięty komponent z własnym interfejsem, druga – samą logikę, z której integrator buduje swoje ekrany. Żadna z nich nie obsłuży wszystkich partnerów, więc dojrzałe biblioteki dają trzy poziomy naraz: gotowe ekrany dla partnerów, którzy chcą wdrożyć się w tydzień; pojedyncze komponenty dla tych, którzy potrzebują wpasować proces w swoją nawigację; oraz warstwę bezinterfejsową (ang. headless) dla firm z rozbudowanym design systemem, które i tak przerysują wszystko po swojemu.

Osadzone okno przeglądarki (ang. WebView) albo pełne przekierowanie do strony dostawcy bywają lepszym wyborem tam, gdzie ekran zmienia się często i musi trafić do wszystkich partnerów natychmiast. Warunek jest jeden: proces nie może sięgać do funkcji urządzenia ani być wpięty w natywną nawigację. Cenę płaci się w płynności i w konwersji, bo każde wyjście poza aplikację to moment, w którym część użytkowników odpada.

Interfejs dostarczany przez bibliotekę wchodzi też w cudzy kontekst dostępności. Czytnik ekranu, powiększona czcionka systemowa, tryb ciemny i nawigacja klawiaturą muszą działać w Twoich ekranach tak samo jak w reszcie aplikacji partnera. Zagadnienia interfejsu i standardów dostępności opisujemy na stronie o warstwie interfejsu użytkownika, a sam audyt gotowej biblioteki mieści się w usłudze Mobilnej Transparentności.

SDK jest produktem, a jego użytkownikiem jest programista

Wybór dostawcy rzadko należy do programisty. Analitykę, monitoring stabilności czy mapy wybiera biznes – idą za nimi umowa i cennik, więc decyzja zapada w rozmowie handlowej albo przy wyznaczaniu kierunku produktu. Programiście zostaje wąski margines: biblioteka do skanowania kodów kreskowych, komponent wykresu, drobne narzędzie pomocnicze. Twoje SDK trafia do niego zwykle jako sprawa już postanowiona, a jego ocena i tak wraca do Ciebie rachunkiem. Programista, który utknie na integracji, eskaluje problem u siebie – Ty płacisz opóźnieniem wdrożenia u partnera i kolejką zgłoszeń do wsparcia. Przy odnowieniu umowy albo przy wyborze dostawcy do kolejnego projektu ktoś o tę ocenę zapyta.

Da się to zmierzyć jedną liczbą: ile mija od otwarcia dokumentacji do pierwszej poprawnie zakończonej operacji w środowisku testowym. Godzina to dobry wynik. Trzy dni oznaczają, że część partnerów nigdy nie dojdzie do końca.

Na ten wynik składa się instalacja standardowym menedżerem zależności, sensowne ustawienia domyślne, czytelne komunikaty błędów, środowisko testowe (ang. sandbox) z danymi do logowania od ręki, dokumentacja migracji między wersjami oraz działająca aplikacja przykładowa.

Aplikacja demonstracyjna SDK Autopay (Norbsoft) uruchomiona obok kodu biblioteki. Integrator widzi docelowe zachowanie w kilka minut, zamiast rekonstruować je z dokumentacji.

Aplikacja demonstracyjna bywa traktowana jako dodatek, a jest najtańszym narzędziem wsparcia, jakie dostawca ma do dyspozycji. Przy SDK Autopay powstała pełnoprawna aplikacja odtwarzająca docelowe środowisko integracyjne: pozwala przejść całą ścieżkę płatności, przetestować poszczególne metody, sprawdzić obsługę zgód, opłat i scenariuszy błędnych, porównać tryb natywny z osadzonym oknem przeglądarki i wykonać podstawową personalizację widoków bez ruszania kodu integracyjnego. Nix robi to samo: do swojego SDK dołącza w pełni działającą aplikację demonstracyjną z kodem źródłowym.

Na iOS domyślnym kanałem dystrybucji jest Swift Package Manager; CocoaPods służy dziś wyłącznie kompatybilności wstecznej, bo repozytorium pakietów CocoaPods przechodzi w tryb tylko do odczytu 2 grudnia 2026 roku – istniejące wersje pozostaną instalowalne, ale nowych opublikować się nie da. Na Androidzie standardem jest Maven Central. Przy przebudowie SDK Autopay obie te zmiany były częścią zakresu: wcześniej pakiet trzeba było pobierać ręcznie ze strony dostawcy, a na Androidzie dołączać plik biblioteki do projektu. Po zmianie aktualizacja sprowadza się do podniesienia numeru wersji w konfiguracji projektu.

Koszt, którego nie widać w wycenie

Publikacja pierwszej wersji nie kończy projektu – zaczyna go. Rachunek utrzymaniowy jest w dużej mierze narzucony z zewnątrz i nie podlega negocjacji.

Do tego dochodzi dyscyplina, której w zwykłej aplikacji nie ma. Publiczne API biblioteki jest kontraktem: zmiana nazwy metody albo zachowania oznacza pracę u wszystkich partnerów naraz. Potrzebne są więc wersjonowanie semantyczne, jawna polityka kompatybilności wstecznej, oznaczanie funkcji jako przestarzałych zamiast ich usuwania oraz instrukcje migracji dołączane do każdego wydania.

Osobno stoi diagnostyka zdalna. Dostawca biblioteki nie ma dostępu do środowiska partnera, więc opiera się na tym, co sam wbudował: identyfikatorach diagnostycznych, opcjonalnym logowaniu, jednoznacznych kodach błędów i procedurze zbierania danych od integratora. Bez tego każde zgłoszenie zaczyna się od tygodnia korespondencji.

Ekonomia utrzymania bywa argumentem za oddaniem tej pracy na zewnątrz – rozkładamy ją w tekście o tym, kiedy własny zespół mobilny przestaje się opłacać, a w ofercie odpowiada jej utrzymanie w reżimie SLA.

Opór po drugiej stronie

Założenie, że partnerzy chętnie przyjmą kolejną bibliotekę, jest dziś najsłabszym punktem wielu uzasadnień biznesowych. W rozmowach o integracjach pierwsze pytanie partnera coraz rzadziej dotyczy funkcji, a coraz częściej kosztu wpuszczenia obcego kodu do aplikacji. Powody są trzy.

Pierwszy to odpowiedzialność. Apple stawia sprawę wprost w wytycznych weryfikacji aplikacji (App Review Guidelines): to wydawca aplikacji odpowiada za zgodność wszystkiego, co się w niej znajduje, „włącznie z sieciami reklamowymi, usługami analitycznymi i SDK firm trzecich – wybieraj je więc uważnie". Google formułuje to samo od strony dostawcy biblioteki: aplikacje korzystające z SDK mogą naruszyć zasady sklepu i narazić się na sankcje ze strony Google Play, z usunięciem z katalogu włącznie. Błąd w Twojej bibliotece staje się problemem regulacyjnym Twojego partnera.

Drugi to publicznie dostępne dane o bibliotekach. Zanim partner się z Tobą skontaktuje, sprawdzi Twoje SDK w Google Play SDK Index, który zbiera ponad sto najczęściej używanych bibliotek komercyjnych i pokazuje przy każdej rozkład używanych wersji, żądane uprawnienia, wskaźniki utrzymania oraz deklarację zgodności z zasadami sklepu.

Trzeci to koszty techniczne, które ponosi wyłącznie integrator: rozmiar paczki, czas uruchamiania aplikacji, zużycie pamięci i baterii, konflikty zależności oraz podniesiona minimalna wersja systemu. Awaria w bibliotece wywraca całą aplikację partnera i to on zbierze za nią oceny w sklepie.

Zestaw, który dawniej uchodził za dojrzałość produktu – minimalna liczba zależności, manifest prywatności, podpisane artefakty, opis zbieranych danych, możliwość wyłączenia telemetrii, mierzalny wpływ na czas startu – jest dziś warunkiem wejścia. Policz go w budżecie pierwszej wersji.

Osadzić czy przekierować: kto zostaje z klientem

Sposób integracji wynika z jednej decyzji biznesowej: czy usługa ma zbierać jak najwięcej transakcji w cudzych aplikacjach, czy budować własną bazę użytkowników? Przy pierwszej odpowiedzi SDK staje się głównym argumentem sprzedażowym. Przy drugiej zostaje dodatkiem do oferty.

Do wyboru są cztery warianty i każdy inaczej rozkłada kontrolę nad procesem oraz nad danymi:

• API i wygenerowany klient. Partner pisze własne ekrany i sam prowadzi użytkownika. Ty odpowiadasz za to, co dzieje się na serwerze.
• Ekrany utrzymywane przez Ciebie. Partner wstawia u siebie widok, który dostarczasz i aktualizujesz. Przebieg procesu kontrolujesz, trudniej natomiast wpasować się w wygląd jego aplikacji.
• Link głęboki do Twojej aplikacji. Użytkownik opuszcza aplikację partnera i kończy sprawę u Ciebie.
• Natywne SDK w aplikacji partnera. Cały proces biegnie u niego, na ekranach z Twojej biblioteki.

Tylko jeden z tych wariantów przenosi użytkownika do Ciebie: link głęboki. Pozostałe zostawiają go u partnera, a razem z nim historię transakcji i kanał komunikacji marketingowej. Przekierowanie buduje więc Twoją własną bazę. Osadzone SDK oddaje ten kontakt partnerowi, a w zamian daje wolumen i wejście do aplikacji, które nie wypuszczają użytkownika na zewnątrz w trakcie zakupu. Jest też wariant pośredni: proces biegnie w aplikacji partnera, a do Twojej przechodzi tylko moment autoryzacji.

Polski rynek usług dodanych w bankowości pokazuje, co się dzieje, gdy gotowego SDK nie ma. Bilety komunikacji, opłaty parkingowe, przejazdy autostradami czy eSIM działają w aplikacjach większości dużych banków, a dostarczają je wyspecjalizowani operatorzy – mapę „kto dostarcza co" rozpisaliśmy w tekście o usługach dodanych w bankowej super-aplikacji. Prawie żaden z nich nie publikuje dokumentacji integracyjnej, więc każde wdrożenie trzeba wynegocjować i zaprogramować od nowa. Dostawca rośnie wtedy liniowo: kolejny bank zajmuje tyle samo pracy co poprzedni. Bank płaci długim wdrożeniem i czeka na wolne terminy jednego zespołu.

W tę lukę wchodzi SDK prowadzone jak produkt: z publiczną dokumentacją, środowiskiem testowym i wersjonowaniem. Najważniejsza zmiana jest organizacyjna – taka biblioteka dostaje własny budżet i osobę, która za nią odpowiada.

Osobny przypadek to SDK wewnętrzne, używane przez kilka aplikacji jednej organizacji lub grupy kapitałowej – logowanie, warstwa bezpieczeństwa, design system, integracje sprzętowe. Ma sens pod warunkiem, że dostanie właściciela produktu, stabilne API, dokumentację i własny cykl wydawniczy. Bez tego zostaje współdzielona biblioteka, w której każdą zmianę trzeba uzgodnić ze wszystkimi zespołami naraz.

Zanim zdecydujesz

Pytania, na które trzeba znać odpowiedź przed startem projektu:

• Jaki trudny problem przejmujemy od partnera? Jeśli sprowadza się on do „wywoływania naszych adresów API", produkt nie jest potrzebny.
• Ilu partnerów wdroży to w podobny sposób? Przy mniej niż kilku integracjach rachunek zwykle się nie domyka.
• Kto jest właścicielem biblioteki po wydaniu? Wpisz imię i nazwisko konkretnej osoby.
• Jaki jest budżet na drugi i trzeci rok? Utrzymanie bywa droższe niż pierwsza wersja.
• Które platformy w pierwszym wydaniu? iOS i Android natywnie; warstwy dla Fluttera i React Native dopiero po ustabilizowaniu API.
• Co zostaje na serwerze? Sekrety, autoryzacja, reguły zmieniające się częściej niż raz na kwartał.
• Jak wygląda pierwsza godzina integratora? Instalacja, klucz testowy, aplikacja przykładowa, pierwsza udana operacja.
• Jak komunikujemy zmiany łamiące zgodność? Polityka wersji i okno wsparcia ustalone przed pierwszym wydaniem, nie po nim.
• Ile kosztuje partnera nasza obecność? Rozmiar paczki, czas startu, uprawnienia, minimalna wersja systemu.

Norbsoft tworzy aplikacje mobilne na iOS i Androida od 2003 roku, z ponad 200 zrealizowanymi projektami używanymi w 45 krajach, a biblioteki dla klientów buduje zarówno wokół komunikacji ze sprzętem, jak i wokół ekosystemów płatności. Jeśli rozważasz udostępnienie swojej usługi partnerom, w formie SDK albo w jednym z modeli pośrednich, porozmawiajmy o zakresie i wykonalności.

Najczęściej zadawane pytania (FAQ)

Czym różni się SDK od API?

API określa sposób komunikacji z usługą: adresy, format danych i kody błędów. SDK to gotowy pakiet do osadzenia w aplikacji, zawierający kod, modele, konfigurację, obsługę błędów, dokumentację, przykłady, a często także natywny interfejs. API mówi, jak rozmawiać z usługą; SDK wykonuje tę rozmowę za integratora.

Kiedy własne SDK się opłaca?

Gdy usługa korzysta z funkcji urządzenia, musi działać offline lub w tle, obsługuje wieloetapowy proces albo ma wyglądać natywnie – i gdy wielu partnerów wdroży ją w podobny sposób. Drugi warunek jest równie ważny: firma musi mieć właściciela produktu i budżet na wieloletnie utrzymanie biblioteki.

Ile kosztuje utrzymanie SDK po wydaniu pierwszej wersji?

Kosztem sterują zdarzenia zewnętrzne, na które dostawca nie ma wpływu. Coroczne wymagania sklepów co do wersji systemu, zmiany zasad prywatności, nowe API platform i konieczność równoległego wspierania kilku wersji biblioteki sprawiają, że utrzymanie bywa droższe niż budowa. Bez zabezpieczonego budżetu biblioteka dezaktualizuje się w ciągu roku.

Czy SDK powinno mieć gotowy interfejs, czy tylko logikę?

Najlepiej oba poziomy naraz: gotowe ekrany dla szybkich wdrożeń, pojedyncze komponenty do wpasowania w cudzą nawigację oraz warstwę bezinterfejsową dla firm z własnym design systemem. Taki podział obsługuje zarówno małych partnerów, jak i duże organizacje, które i tak przerysują wszystko po swojemu.

Jak dystrybuować SDK na iOS i Androida?

Na iOS domyślnym kanałem jest Swift Package Manager; CocoaPods pozostaje wyłącznie dla kompatybilności wstecznej, bo repozytorium pakietów przechodzi w tryb tylko do odczytu 2 grudnia 2026 roku. Na Androidzie standardem jest Maven Central. Dodatkowo potrzebne są podpisane artefakty, symbole debugowania, informacje o wydaniu i kontrolowane wydania testowe.

Czego partnerzy wymagają, zanim wpuszczą obce SDK do aplikacji?

Minimalnej liczby zależności, manifestu prywatności i podpisu wymaganych przez Apple, jawnego opisu zbieranych danych, możliwości wyłączenia telemetrii oraz mierzalnego wpływu na rozmiar paczki i czas uruchamiania. Wydawca aplikacji odpowiada wobec sklepów za cały kod, który w niej umieści, łącznie z cudzym.