Teleprompter na macOS pod notch MacBooka: budowa natywnej aplikacji w Swift

Kontakt wzrokowy podczas rozmów wideo to problem rozwiązany w teorii, ale w praktyce nie do zrealizowania. Twoje notatki są na drugim ekranie, w aplikacji Notion lub: co gorsza: w twojej głowie. W chwili, gdy spoglądasz w lewo, rozmówca to zauważa.

Chciałem mieć aplikację, która wyświetla się dokładnie w miejscu, gdzie znajduje się aparat. W przypadku modelu „MacBook Pro” oznacza to obszar wycięcia u góry wyświetlacza. Tekst wyświetlany w tym miejscu jest wizualnie powiązany z aparatem, co po raz pierwszy pozwala czytanie przy zachowaniu naturalnego kontaktu wzrokowego.

Dlaczego warto budować, a nie kupować

Przejrzałem dostępne aplikacje do wyświetlania tekstu. Większość z nich jest przeznaczona do nagrywania filmów: przewijają długi tekst ze stałą prędkością. Nie tego jednak potrzebowałem. Potrzebowałem:

• Małe, trwałe okienko w pobliżu wycięcia
• Punkty, które mogę przeglądać ręcznie
• Brak przejęcia całego ekranu
• Coś, co uruchamia się i znika bez zbędnych ceregieli

W App Store nie znalazłem niczego, co by temu dorównywało. Postanowiłem więc stworzyć to sam.

Przebieg pracy w systemie Codex

Zacząłem tę pracę, mając jedynie podstawową wiedzę na temat Swift i nie mając żadnego niedawnego doświadczenia z AppKit. Codex zmienił to, co było możliwe do zrealizowania.

Przebieg pracy wyglądał następująco:

1. 1 Opisz interfejs użytkownika

   Opis w przystępnym języku tego, czego chciałem: położenie okna, sposób działania, skróty klawiszowe.

2. 2 Codex generuje

   Swift /Struktura AppKit, kod szablonowy, elementy interfejsu okna, konfiguracja NSPanel.

3. 3 Przegląd i test

   Uruchom symulator, sprawdź zachowanie w odniesieniu do modelu mentalnego, dostosuj opis.

4. 4 Powtórz

   Powtarzaj tę czynność, aż zachowanie będzie zgodne z oczekiwaniami. Zazwyczaj wystarczy 3–5 rund na każdą funkcję.

Codex dobrze radzi sobie z elementami standardowymi: elementami interfejsu okna, skrótami klawiaturowymi, ikonami na pasku menu oraz konfiguracją NSPanel. Radzi sobie również z lukami koncepcyjnymi: wystarczy opisać zachowanie („Chcę, żeby to okno pozostawało na wierzchu, nie pojawiało się w Mission Control i nie przejmowało fokusu”), a w zamian otrzymuję odpowiednie flagi konfiguracyjne NSPanel.

Codex nie zajmuje się kwestią estetyki. Początkowy rozmiar okna był nieodpowiedni, odstępy wydawały się zbyt małe, a wybór czcionek nie był trafiony. Każda decyzja dotycząca doświadczenia użytkownika należała do mnie. Codex realizuje zadania; ja podejmuję decyzje.

Kształt techniczny

NotchCue to standardowe narzędzie macOS z kilkoma celowymi ograniczeniami:

Result %

Baseline %

Najciekawszym wyzwaniem było wykrywanie wycięcia w wyświetlaczu. Codex pomógł mi osiągnąć 80% tego celu; pozostałe 20% (obsługa wielu wyświetlaczy, wykrywanie dokładnej wysokości wycięcia dla każdego modelu z serii MacBook) wymagało ode mnie samodzielnego przeglądania dokumentacji Apple.

Co to dowodzi

Możliwości samodzielnego tworzenia aplikacji natywnych przy pomocy AI są większe, niż większość ludzi sądzi. Projekt NotchCue przeszedł od pomysłu do działającej wersji w ciągu jednego weekendu. Jeszcze rok temu wymagałoby to albo wcześniejszej znajomości Swift, albo zatrudnienia zewnętrznego wykonawcy.

Schemat: opisanie zamierzonego celu, sprawdzenie wyniku, dostosowanie do własnych preferencji, wydanie — jest powtarzalny. Od tamtej pory wykorzystałem go przy tworzeniu trzech innych niewielkich narzędzi macOS.

---

Zobacz też: Jak stworzyć mikro-SaaSa przy użyciu narzędzi opartych na sztucznej inteligencji: wnioski dotyczące produktu z ponad 10 uruchomionych aplikacji · Jak stworzyć system rezerwacji: decyzje dotyczące architektury produktu dla rynków wertykalnych