Помните, когда мы думали, что разгадали код? Ещё в 1995 году Sun Microsystems смело провозгласила «Write Once, Run Anywhere» (WORA) сверхспособностью Java. Перемотаем на 2025 год, и мы всё ещё гонимся за той же неуловимой мечтой с React Native, Flutter и множеством фреймворков, обещающих стать «фреймворком, который покорит всех».

Спойлер: мы всё ещё занимаемся отладкой повсюду.

Позвольте мне быть предельно откровенным: после нескольких лет борьбы с кроссплатформенной разработкой, наблюдая, как проекты превращаются в кошмары обслуживания, и видя, как разработчики ломают голову над специфическими особенностями платформ, я пришёл к спорному выводу: WORA не просто переоценена; она принципиально ошибочна как философия.

Но прежде чем вы схватитесь за вилы, выслушайте меня. Речь не идёт о полном отрицании кроссплатформенной разработки. Речь идёт о понимании, почему обещание не оправдывается и как мы можем сделать лучше.

Соблазнительное обещание, которое никогда не оправдывает ожиданий

Привлекательность, бесспорно, опьяняет. Представьте: вы пишете код один раз, нажимаете волшебную кнопку развёртывания, и вуаля — ваше приложение отлично работает на iOS, Android, в веб-версии, Windows, macOS и, возможно, даже на вашем умном тостере. Больше не нужно поддерживать отдельные кодовые базы, больше нет специфичных для платформы ошибок, больше не нужно объяснять заинтересованным сторонам, почему версия для iOS стоит вдвое дороже, чем было заявлено изначально.

Современные фреймворки, безусловно, сделали эту мечту более осязаемой:

  • React Native с React Native Web — совместное использование кода между мобильными устройствами и вебом.
  • Flutter — решение от Google на базе Dart для нескольких платформ.
  • Kotlin Multi-Platform — подход JetBrains к совместному использованию кода.
  • Ionic — веб-технологии в нативных контейнерах.

Эти инструменты действительно сокращают дублирование кода и могут ускорить разработку. Но вот где реальность разбивает вечеринку, как незваный родственник на ужин в День благодарения.

Суровая реальность: различия платформ — это особенности, а не ошибки

Давайте рассмотрим реальный пример. Представьте, что вы создаёте простой компонент выбора файлов. Звучит просто, верно?

// Идеалистическая версия WORA
function FilePicker({ onFileSelect }) {
  const handleFileSelection = () => {
    // Это должно «просто работать» везде, верно?
    const file = selectFile();
    onFileSelect(file);
  };
  return (
    <TouchableOpacity onPress={handleFileSelection}>
      <Text>Pick a File</Text>
    </TouchableOpacity>
  );
}

Теперь давайте посмотрим, что на самом деле нужно этому «простому» компоненту на разных платформах:

// Суровая реальность
import { Platform } from 'react-native';
import DocumentPicker from 'react-native-document-picker';
import { launchImageLibrary } from 'react-native-image-picker';
function FilePicker({ onFileSelect, fileType = 'any' }) {
  const handleFileSelection = async () => {
    try {
      if (Platform.OS === 'web') {
        // Реализация для веба
        const input = document.createElement('input');
        input.type = 'file';
        input.accept = getWebAcceptString(fileType);
        input.onchange = (e) => onFileSelect(e.target.files);
        input.click();
      } else if (Platform.OS === 'ios') {
        // У iOS свои особенности разрешений и UX-шаблонов
        const result = await DocumentPicker.pickSingle({
          type: getIOSDocumentTypes(fileType),
          copyTo: 'documentDirectory' // Требование специфичное для iOS
        });
        onFileSelect(result);
      } else if (Platform.OS === 'android') {
        // Android по-своему обрабатывает доступ к файлам
        const result = await DocumentPicker.pickSingle({
          type: getAndroidMimeTypes(fileType),
          // В большинстве случаев Android не нуждается в copyTo
        });
        onFileSelect(result);
      }
    } catch (error) {
      if (DocumentPicker.isCancel(error)) {
        // Обработка отмены — но подождите, в вебе такого нет!
        if (Platform.OS !== 'web') {
          console.log('Пользователь отменил выбор файла');
        }
      } else {
        // Обработка ошибок специфичных для платформы
        handlePlatformSpecificError(error);
      }
    }
  };
  // Разные UI-компоненты нужны для разных платформ
  if (Platform.OS === 'web') {
    return (
      <button onClick={handleFileSelection} className="file-picker-btn">
        Выбрать файл
      </button>
    );
  }
  return (
    <TouchableOpacity 
      onPress={handleFileSelection}
      style={Platform.select({
        ios: styles.iosButton,
        android: styles.androidButton,
      })}
    >
      <Text style={Platform.select({
        ios: styles.iosText,
        android: styles.androidText,
      })}>
        Выбрать файл
      </Text>
    </TouchableOpacity>
  );
}

Внезапно наш компонент «напиши один раз» превратился в лабиринт условных операторов, специфичных для платформы. И это только выбор файла — представьте себе обработку доступа к камере, push-уведомлений или глубоких ссылок!

Техническая реальность: почему WORA терпит неудачу

Фундаментальная проблема не в самих фреймворках — они выдающиеся инженерные достижения. Проблема заключается в предположении, что платформы — это просто разные оболочки одной и той же базовой системы.

graph TD A[Обещание WORA] --> B[Единая кодовая база] B --> C[Развёртывание везде] D[Реальность] --> E[Особенности iOS] D --> F[Различия Android] D --> G[Ограничения веба] D --> H[Вариации для настольных систем] E --> I[Код специфичный для платформы] F --> I G --> I H --> I I --> J[Условная логика повсюду] I --> K[Увеличение сложности] I --> L[Кошмар обслуживания] B -.->|"Становится"| I C -.->|"Превращается в"| L

Различия операционных систем глубоки

Даже что-то такое простое, как пути к файлам, становится головной болью:

# Пример обработки файлов, кроссплатформенный
import os
import platform
def get_config_path():
    if platform.system() == "Windows":
        return os.path.join(os.environ['APPDATA'], 'MyApp', 'config.json')
    elif platform.system() == "Darwin":  # macOS
        return os.path.expanduser('~/Library/Application Support/MyApp/config.json')
    else:  # Linux и другие
        return os.path.expanduser('~/.config/myapp/config.json')
# То, что мы хотели бы написать:
# return get_universal_config_path()  # Этого не существует

Ожидания пользователей по поводу UX сильно различаются

Пользователи iOS ожидают плавных анимаций и навигации на основе жестов. Пользователи Android привыкли к аппаратным кнопкам «Назад» и шаблонам Material Design. Веб-пользователи думают в терминах URL и элементов управления браузером. Пользователи настольных систем хотят сочетания клавиш и изменяемых окон.

Поистине кроссплатформенное приложение, которое игнорирует эти различия, кажется чужим на каждой платформе — пугающая «долина uncanny valley» пользовательских интерфейсов.

Заблуждение Docker: контейнеры не решают всего

«А как же контейнеры?» — спросите вы. Docker обещал решить проблему развёртывания WORA, но приносит свои ограничения:

# Этот Dockerfile отлично работает... на Linux
FROM node:16-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]
# Но удачи вам запустить этот контейнер Windows на Linux:
# FROM mcr.microsoft.com/windows/nanoserver:1809
# Это просто не будет работать на хосте Linux

Контейнеры зависят от ОС. Вы не можете запустить контейнер Windows на Linux, и специфические для платформы зависимости всё равно прокрадываются через нативные модули, системные вызовы и взаимодействие с оборудованием.

Лучшая философия: стратегическое совместное использование кода

Вместо того чтобы заставлять всё в единую кодовую базу, успешные кроссплатформенные проекты используют стратегическое совместное использование кода. Вот как это выглядит на практике:

Общий уровень бизнес-логики

// shared/userService.ts - Независим от платформы
export class UserService {
  private apiClient: ApiClient;
  constructor(