iOS Simulator: co to jest i jak działa w Xcode

Czym jest Simulator w Xcode?

Xcode Simulator — narzędzie do uruchamiania i debugowania aplikacji iOS bezpośrednio na Macu. W przeciwieństwie do emulatora Androida, symulator Apple nie emuluje procesora ARM urządzenia. Zamiast tego kod jest kompilowany do kodu maszynowego architektury hosta (x86_64 na Intel Mac lub arm64 na Apple Silicon).

Symulator korzysta z frameworków iOS bezpośrednio z SDK, zapewniając dostęp do UIKit, SwiftUI, Foundation i Core Data. Według Apple (WWDC 2024), ponad 90% programistów używa symulatora na etapie rozwoju, podłączając fizyczne urządzenia tylko do końcowego testowania.

Każda wersja Xcode zawiera zestaw symulatorów dla różnych modeli urządzeń i wersji iOS. Na przykład Xcode 16 zawiera symulatory iPhone 16 Pro z iOS 18, iPad Pro M4 z iPadOS 18, Apple Watch Series 10 i Apple TV 4K.

Instalacja i uruchamianie symulatora

Symulator instaluje się wraz z Xcode z Mac App Store. Aby dodać dodatkowe wersje iOS, użyj menu Settings → Platforms. Wybierz symulator w schemacie kompilacji (Scheme) i naciśnij Run. Alternatywnie uruchom symulator przez menu Xcode → Open Developer Tool → Simulator.

// Sprawdzanie minimalnej wersji iOS dla symulatora
if #available(iOS 18.0, *) {
    print("API iOS 18 dostępne")
}

Różnice między symulatorem a rzeczywistym urządzeniem

Zrozumienie różnic między symulatorem a rzeczywistym urządzeniem jest kluczowe dla wysokiej jakości testowania. Główne różnice dotyczą architektury procesora, możliwości sprzętowych i wydajności grafiki.

Wydajność w symulatorze jest zazwyczaj wyższa niż na rzeczywistym urządzeniu, ponieważ wykorzystuje mocny procesor Mac. Stwarza to fałszywe wrażenie szybkości działania. Animacje, praca z Core Data i żądania sieciowe na rzeczywistym urządzeniu mogą działać wolniej.

Kiedy konieczne jest testowanie na urządzeniu

Obowiązkowo uruchamiaj aplikację na rzeczywistym urządzeniu przed wydaniem. Krytyczne scenariusze: aparat i AVFoundation, Bluetooth i CoreBluetooth, powiadomienia push przez APNs, praca z systemem plików w App Sandbox, wydajność grafiki w Metal oraz zużycie baterii.

Sprawdzanie TARGET_OS_SIMULATOR w kodzie

Do warunkowej kompilacji kodu dla symulatora Apple udostępnia TARGET_OS_SIMULATOR w Objective-C i targetEnvironment(simulator) w Swift. To sprawdzenie pozwala dodać logi debugowania, obiekty mok lub wyłączyć kod zależny od sprzętu.

import UIKit

class CameraViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        
        #if targetEnvironment(simulator)
        showMockCameraPreview()
        print("Symulator: używamy mok-kamery")
        #else
        setupRealCameraSession()
        #endif
    }
}

W Objective-C dyrektywa #if TARGET_OS_SIMULATOR działa podobnie. Użyj jej do wyłączenia kodu wymagającego czujników sprzętowych lub aparatu. Na etapie kompilacji dla symulatora ten kod nie trafia do pliku binarnego.

#if TARGET_OS_SIMULATOR
NSLog(@"Uruchomienie w symulatorze — kamera niedostępna");
self.cameraButton.hidden = YES;
#else
self.cameraButton.hidden = NO;
#endif

Typowe scenariusze użycia sprawdzania

Sprawdzanie TARGET_OS_SIMULATOR stosuje się w trzech przypadkach: zastąpienie aparatu obiektem mok podczas testów UI, wyłączenie Core Bluetooth w celu przyspieszenia rozwoju oraz logowanie informacji debugowania, które nie powinny trafić do wersji wydaniowej. Unikaj używania sprawdzania do zmiany logiki biznesowej — może to prowadzić do błędów na rzeczywistym urządzeniu.

Uruchamianie testów w symulatorze

Xcode Simulator obsługuje pełny zestaw testów XCTest: testy jednostkowe (XCTestCase), testy UI (XCUITestCase) i testy wydajnościowe. Do testowania na symulatorze nie jest wymagany podpisany certyfikat deweloperski, co upraszcza konfigurację CI/CD.

import XCTest

final class LoginTests: XCTestCase {
    var app: XCUIApplication!
    
    override func setUp() {
        continueAfterFailure = false
        app = XCUIApplication()
        app.launch()
    }
    
    func testLoginButtonExists() {
        XCTAssertTrue(app.buttons["loginButton"].exists)
    }
    
    func testEmptyEmailValidation() {
        app.textFields["emailField"].tap()
        app.buttons["loginButton"].tap()
        let errorLabel = app.staticTexts["errorMessage"]
        XCTAssertTrue(errorLabel.exists)
    }
}

Do uruchamiania testów z wiersza poleceń użyj xcodebuild test z podaniem schematu i symulatora. Parametr -destination określa konkretny symulator, na którym zostaną uruchomione testy.

# Uruchamianie testów jednostkowych na symulatorze iPhone 16, iOS 18
xcodebuild test \
  -scheme "MyApp" \
  -destination "platform=iOS Simulator,name=iPhone 16,OS=18.0" \
  -testPlan "AllTests"

Ograniczenia i pułapki

Pomimo wygody, Xcode Simulator ma szereg ograniczeń, które mogą prowadzić do błędów na rzeczywistym urządzeniu. Najbardziej krytyczne jest brak emulacji ARM: kod jest kompilowany pod architekturę hosta, a zachowanie niektórych operacji może się różnić.

Core Data i system plików działają szybciej na symulatorze z powodu SSD Mac. Na rzeczywistym urządzeniu z pamięcią NAND prędkość odczytu/zapisu jest niższa. Testuj wydajność Core Data na urządzeniu przed wydaniem, szczególnie dla dużych zbiorów danych.

Sprawdzanie poboru energii na symulatorze jest niemożliwe — symulator jest zasilany z Maca. Tryby tła, w tym pobieranie treści i operacje fetch, zachowują się inaczej na rzeczywistym urządzeniu z powodu ograniczeń baterii i Background Task Scheduler.

Czujniki sprzętowe i biometria

Symulator nie ma dostępu do czujników sprzętowych iPhone. Face ID i Touch ID można symulować przez menu symulatora: Features → Face ID → Matching Face. Akcelerometr, żyroskop i barometr są niedostępne — kod polegający na CMDeviceMotion należy testować na urządzeniu. Dla Core Location można ustawić współrzędne przez Debug → Simulate Location z wyborem pliku GPX.

Sprawdzanie iCloud i StoreKit na symulatorze jest również ograniczone. StoreKit Test pozwala symulować zakupy bez rzeczywistego App Store Connect, ale sprawdzenie środowiska Sandbox i zakupów produkcyjnych wymaga fizycznego urządzenia. Synchronizacja iCloud Drive i CloudKit w symulatorze działa nieprawidłowo — Apple zaleca testowanie tych scenariuszy tylko na rzeczywistych urządzeniach.

Symulator na Macu Apple Silicon

Na Macu z procesorami serii M symulator działa zasadniczo inaczej: kod jest kompilowany do natywnego ARM64, jak na prawdziwym iPhonie, a nie do x86_64. To znacznie zmniejsza przepaść między symulatorem a urządzeniem. Aplikacje uruchomione na symulatorze Apple Silicon używają tych samych instrukcji ARM, co na fizycznym iPhonie, co czyni testy wydajnościowe bardziej reprezentatywnymi. Różnica w wydajności Metal i Core Animation między symulatorem serii M a rzeczywistym iPhonem jest minimalna w porównaniu z symulatorem Intel.

Konfiguracja symulatora dla CI

Konfiguracja symulatora dla CI wymaga wcześniejszego utworzenia potrzebnego urządzenia i wersji iOS. Na serwerach Continuous Integration symulatory nie są tworzone automatycznie — trzeba je dodać przez xcrun simctl create przed uruchomieniem testów.

# Tworzenie symulatora dla CI
xcrun simctl create \
  "iPhone 16 CI" \
  "com.apple.CoreSimulator.SimDeviceType.iPhone-16" \
  "com.apple.CoreSimulator.SimRuntime.iOS-18-0"

# Uruchamianie testów na utworzonym symulatorze
xcodebuild test \
  -workspace MyApp.xcworkspace \
  -scheme MyApp \
  -destination "id=$(xcrun simctl list devices | grep 'iPhone 16 CI' | awk -F'[][]' '{print }')"

Do testowania równoległego na CI skonfiguruj kilka symulatorów z różnymi wersjami iOS. Xcode Cloud, GitHub Actions i Bitrise obsługują równoległe uruchamianie testów, co skraca czas wykonania 2-3 razy. Upewnij się, że na serwerze CI są zainstalowane wszystkie niezbędne symulatory iOS do testowania.