[Development Diary Day1] Me gusta tanto Captio que quería hacer "esa experiencia" de nuevo

En el desarrollo de iOS en 2026, puede parecer extraño elegir UIKit en lugar de SwiftUI. Sin embargo, nuestro objetivo de máxima prioridad era claro: Tiempo para enviar mensajes de texto 500ms o menos.

Reevaluación `body` de SwiftUI, inicialización `StateObject`, resolución `@Environment` - estos gastos generales se pueden ignorar en el desarrollo normal de aplicaciones, pero no se pueden ignorar para lograr el "inicio y la entrada". Quiero centrarme en el campo de texto rápidamente, incluso con 1ms.

Lo que se adoptó allí es la construcción directa de UIKit sin usar Storyboard.

Crea una ventana con SceneDelegate y establece el ComposeViewController directamente en el rootViewController. Omita incluso el proceso de análisis de Storyboard.

// SceneDelegate.swift
func scene(_ scene: UIScene,
           willConnectTo session: UISceneSession,
           options connectionOptions: UIScene.ConnectionOptions) {
    guard let windowScene = (scene as? UIWindowScene) else { return }
    let window = UIWindow(windowScene: windowScene)
    window.rootViewController = ComposeViewController()
    window.makeKeyAndVisible()
    self.window = window
}

y con `viewDidAppear` en ComposeViewController, enfóquese instantáneamente en la vista de texto.

// ComposeViewController.swift
override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    textView.becomeFirstResponder()
}

Solo con este código 2, el camino desde el inicio hasta la pantalla del teclado es el más corto.

El objetivo es 500ms o menos. En el registro medido más tarde por grabación de pantalla (2026 8 11, iPhone 16e, inicio en caliente), fue 0.4 segundos desde el toque del icono hasta la pantalla del teclado. En SwiftUI, es difícil controlar el tiempo de `@FocusState` y la reevaluación del cuerpo en detalle, y es difícil empaquetar este camino (los dos no se midieron y compararon en las mismas condiciones).

UIKit puede ser "viejo". Sin embargo, "rápido". En este punto 1, UIKit sigue siendo la mejor opción.

Existe el juicio de diseño más importante para reproducir la experiencia de "desaparece cuando se envía" del Captio. Es para separar completamente la animación de transmisión y la limpieza de la interfaz de usuario de la respuesta de red.

El flujo de transmisión de las aplicaciones comunes es el siguiente:

1. Presione el botón de enviar
2. Mostrar indicador de carga
3. Esperando una respuesta del servidor
4. Borrar la interfaz de usuario si tiene éxito, mostrar el error si falla

En este flujo, el retraso de red se convierte en el retraso de la interfaz de usuario tal como está. Nuestro flujo es así:

1. Presione el botón de enviar
2. inmediatamenteborrar interfaz de usuario (animación: 0.25 segundos)
3. Transmisión de red en segundo plano
4. Éxito → Eliminar silenciosamente de la Outbox / Fallado → Reintentar en segundo plano

// ComposeViewController.swift
private func performSendAnimation() {
    UIView.animate(withDuration: 0.25,
                   delay: 0,
                   options: .curveEaseOut) {
        self.textView.alpha = 0
        self.subjectField.alpha = 0
    } completion: { _ in
        self.textView.text = ""
        self.subjectField.text = ""
        self.textView.alpha = 1
        self.subjectField.alpha = 1
        self.textView.becomeFirstResponder()
    }
}

Para los usuarios, en el momento en que se presiona el botón de enviar, la nota "desaparece" y pueden escribir la siguiente nota. El éxito o el fracaso de la red se maneja en un lugar invisible para el usuario.

"¿Pero qué pasa si la transmisión falla?" - La respuesta a esa pregunta es la arquitectura de la Outbox en la siguiente sección.

Separar la interfaz de usuario de transmisión de la respuesta de red significa que puede ocurrir una situación en la que "la interfaz de usuario se borró, pero la transmisión de correo electrónico realmente falló". Esto es absolutamente inaceptable. La nota que el usuario pensó que fue "envió" en realidad no se envió, esto es una pérdida fatal de confianza para la aplicación de notas.

El Patrón de Outbox se adoptó allí.

El flujo de envío de mensajes es el siguiente:

1. Toque el botón de enviar: Cifre el mensaje AES-GCM y guárdelo en la Outbox (almacenamiento local)
2. UI clear: Borra la pantalla al instante con performSendAnimation
3. Transmisión en segundo plano: Extrae un mensaje de la Outbox y envíelo a Relay API
4. Éxito: Eliminar mensaje de la Outbox
5. Fallo: Déjalo esperando la transmisión y vuelve a enviarlo más tarde
6. Offline: Supervise la conexión con NWPathMonitor y vuelva a enviarla automáticamente cuando se restablezca

Lo importante es guardarlo en la Outbox antes de transmitirlo a la red. Como resultado, incluso si la aplicación se bloquea repentinamente o el dispositivo se apaga, el mensaje escrito en la Outbox permanecerá.

Los mensajes almacenados en la Outbox están protegidos por el cifrado AES-GCM utilizando CryptoKit. La clave de cifrado se almacena en el llavero y no se puede acceder a ella desde fuera del sandbox de la aplicación.

// OutboxManager.swift
func enqueue(message: OutboxMessage) throws {
    let key = try KeychainHelper.getOrCreateSymmetricKey()
    let sealedBox = try AES.GCM.seal(
        message.plainData,
        using: key
    )
    let encrypted = EncryptedOutboxEntry(
        id: message.id,
        sealedData: sealedBox.combined!,
        createdAt: Date(),
        retryCount: 0
    )
    try persistenceStore.save(encrypted)
}

Además, debido a que todo lo implementas por ti mismo, la dependencia de las bibliotecas externas es cero. CryptoKit, NWPathMonitor, URLSession - todos completados con el marco Apple original. Estar libre del control de versiones de la biblioteca de terceros y la auditoría de seguridad es una gran ventaja para los equipos pequeños.

El mecanismo de transmisión de Captio no se revela oficialmente. La razón del anuncio de terminación del desarrollador es que ya no puede continuar pasando tiempo para mantener la estabilidad y seguridad de la aplicación, y el método de transmisión no se cita como una razón. Sin embargo, en general, el envío confiando en el correo electrónico externo API se ve fácilmente afectado por los cambios en los requisitos del proveedor y las restricciones de acceso.

Elegimos la configuración Cloudflare Workers + Resend API.

Cloudflare Workers es una plataforma informática de borde que ejecuta código en el centro de datos más cercano a los usuarios de todo el mundo. Las solicitudes de Japón se procesan en el borde de Japón, y las solicitudes de los Estados Unidos se procesan en el borde de los Estados Unidos. Esto casi elimina el problema del arranque en frío en comparación con el sin servidor convencional (AWS Lambda, etc.).

Para enviar correo se usa la API de Resend. Resend es una API de envío de correo para desarrolladores.

Flujo de autenticación de correo electrónico

Cuando el usuario establece la dirección de correo electrónico de destino, la autenticación de correo electrónico se realiza con el código de autenticación 6 dígitos. Esto evita el envío no autorizado a direcciones de correo electrónico de terceros.

Límite de velocidad multicapa

Se implementan restricciones de velocidad multicapa para evitar el uso no autorizado.

// Cloudflare Worker - Rate Limit Configuration
const RATE_LIMITS = {
  devicePerMinute: 30,    // 1デバイスあたり1分30回
  devicePerDay: 200,      // 1デバイスあたり1日200回
  ipPerHour: 120,         // 1IPあたり1時間120回
  globalPerDay: 300       // サービス全体で1日300回（調整可能）
};

Al limitar la velocidad en la capa 3 en un dispositivo, IP y global, puede bloquear fugas y ataques de botnet en un solo dispositivo.

2026-09 Postscript: El límite superior para cada terminal y el límite superior del día total 1 se eliminaron en 2026 6. El límite máximo de transmisión actual es el límite superior por 1 horas por dirección IP.

Garantía de igualdad de poder

Para evitar la transmisión duplicada debido a la inestabilidad de la red, asigne un UUID a cada mensaje y realice una comprobación de duplicado en el lado de Relay API. Si se reenvía el mismo mensaje UUID, después del tiempo 2, devolverá una respuesta exitosa sin enviar un correo electrónico. Como resultado, incluso si se combina con el mecanismo de reintento del patrón de Outbox, el usuario no recibirá la misma nota dos veces.

Actualización de 2026-10: el servidor de envío actual no comprueba por sí mismo los duplicados. Pasa el identificador del mensaje como Idempotency-Key en la solicitud a Resend. Resend recuerda la misma clave durante 24 horas y devuelve la respuesta anterior ante una solicitud con el mismo contenido. Así se evita enviar de nuevo la misma nota durante 24 horas. Consulta el diseño de la Relay API.

Gran parte del trabajo de implementación de Day1 se pasó revisando el diálogo de calificación por estrellas. La evaluación de App Store es la línea de vida de la aplicación, pero no busque la evaluación de una manera que perjudique la experiencia del usuario.

Rediseño de las condiciones de visualización

Las condiciones de visualización del cuadro de diálogo de clasificación por estrellas se establecen de la siguiente manera:

• Mostrado cada 100: Mostrar solo a los usuarios que han utilizado la aplicación lo suficiente
• Intervalo mínimo de 14 días: Más de un 14 ha pasado desde la última pantalla
• No volver a mostrar durante 30 días tras cerrarlo: si el usuario lo cierra, no se muestra de nuevo durante 30 días

Corrección del área de toque del icono de la estrella

Apple Las directrices de interfaz humana recomiendan que el tamaño mínimo del objetivo táctil sea 44x44pt. El área de toque del icono de la estrella no cumpía con este estándar, por lo que se corrigió.

// StarRatingView.swift
private func createStarButton() -> UIButton {
    let button = UIButton(type: .custom)
    button.translatesAutoresizingMaskIntoConstraints = false
    NSLayoutConstraint.activate([
        button.widthAnchor.constraint(greaterThanOrEqualToConstant: 44),
        button.heightAnchor.constraint(greaterThanOrEqualToConstant: 44)
    ])
    return button
}

Corrección de distorsión del icono de estrella

UIStackView. `contentMode` se estableció en `.scaleAspectFit`, y la distribución de StackView se cambió a `.equalSpacing`.

Flujo después de la evaluación

• 5 estrellas: Transición a la pantalla de revisión de App Store (`SKStoreReviewController`)
• 4 estrellas o menos: Muestra silenciosamente el brindis de "Gracias" y termina. No conduzca a reseñas negativas a App Store.

Noté un error en la pantalla del historial de transmisión (Historial). Había un mensaje de que el estado seguía siendo "Enviando" a pesar de que la transmisión estaba completa.

Como resultado de la investigación de la causa, se descubrió que había un problema con la lógica de actualización de estado. En implementaciones anteriores, el contenido de texto del mensaje se utilizó como clave para actualizar el estado. Sin embargo, si envía una nota con el mismo contenido más de una vez, una búsqueda basada en texto no puede identificar el mensaje correcto.

La corrección fue sencilla y clara. Se cambió la búsqueda basada en texto a Actualización de estado basada en ID. A cada mensaje se le asigna un UUID al guardar la Outbox, así que use este ID para actualizar el estado del historial.

// HistoryManager.swift
// Before: テキストベースの検索（バグの原因）
// func updateStatus(forText text: String, status: SendStatus)

// After: IDベースのステータス更新
func updateStatus(forMessageId id: UUID, status: SendStatus) {
    guard let index = entries.firstIndex(where: { $0.messageId == id }) else {
        return
    }
    entries[index].status = status
    persistEntries()
}

Con esta corrección, no importa cuántas veces envíes una nota con el mismo contenido, el estado de cada una ahora se muestra correctamente.

La información privada está escrita en la aplicación de notas. Contraseñas, preocupaciones personales, ideas de negocios: es imposible predecir lo que escribirán los usuarios. Es por eso que la protección de la privacidad no es "suficiente", pero "excesiva" es la adecuada.

Superposición de privacidad en el conmutador de aplicaciones

En el conmutador de aplicaciones iOS, la pantalla de la aplicación se muestra como una miniatura. Muestra una superposición de privacidad cuando la aplicación migra al fondo para que el contenido de la nota no se pueda ver desde la pantalla del conmutador de aplicaciones.

2026-09 Postscript: Esta protección no está habilitada en la aplicación actual (el procesamiento de la pantalla permanece en la fuente, pero no se llama). La nota que se muestra puede permanecer en la imagen del conmutador de aplicaciones. Para obtener más información, consulte el artículo sobre "Diseño de privacidad".

Sesión URL efímera

La sesión de URL normal almacena caché, cookies e información de autenticación en el disco. Al usar `URLSessionConfiguration.ephemeral`, nos aseguramos de que esta información no permanezca en el disco en absoluto. Esto es para evitar que el contenido de la nota permanezca en el almacenamiento como una caché de comunicación.

Tracos inofensivos

Tenga cuidado con la depuración de registros bajo desarrollo. " El proceso aparentemente inofensivo de "proportar el contenido de la nota enviada al registro" puede ser un agujero de seguridad. Nuestra política es clara:

• El contenido de la nota no está registrado en absoluto, incluso si es una compilación de DEBUG
• El registro de errores no utiliza `localizedDescription`, solo se registra `type(of: error)`
• Razón: Porque `localizedDescription` puede contener la entrada del usuario

// NetworkManager.swift
// BAD: エラーの詳細をログに出力
// Logger.error("Send failed: \(error.localizedDescription)")

// GOOD: エラーの型のみをログに出力
Logger.error("Send failed: \(type(of: error))")

Puede parecer paranoico. Sin embargo, creo que este grado de paranoia es necesario para confiar y usar la aplicación de notas.

Captio tenía usuarios en todo el mundo, principalmente en países de habla inglesa. Para entregar "SimpleMemo" a los antiguos usuarios, el lenguaje 10 fue compatible desde la primera versión.

Idiomas admitidos: japonés, inglés, español, francés, alemán, italiano, portugués, coreano, chino (simplificado), árabe.

2026-09 Epospítula: En la notación actual App Store, los idiomas admitidos son japonés, inglés, español, francés, alemán, portugués, ruso, chino (simplificado), chino (tradicional) y árabe 10. Los italianos y coreanos de la lista anterior no están incluidos en la notación actual.

Especialmente El soporte árabe de RTL (de derecha a izquierda) fue un desafío técnico. No solo la dirección del texto, sino también todo el diseño de la interfaz de usuario debe reflejarse. Al utilizar constantemente la restricción "liderar"/`trailing" de Auto Layout, se da cuenta de un diseño natural incluso en un entorno RTL.

Cambio de idioma en la aplicación

Además del cambio de idioma en la aplicación después de iOS 16, también implementa su propio mecanismo de cambio de idioma. Cuando se cambia el idioma, el ViewController se reemplaza con la transición `cross-dislove` para proporcionar una experiencia de cambio fluida.

// LanguageManager.swift
func applyLanguageChange() {
    guard let window = UIApplication.shared.connectedScenes
        .compactMap({ $0 as? UIWindowScene })
        .first?.windows.first else { return }

    let newVC = ComposeViewController()
    newVC.view.frame = window.bounds
    UIView.transition(with: window,
                      duration: 0.3,
                      options: .transitionCrossDissolve,
                      animations: {
        window.rootViewController = newVC
    })
}