Goal
Provide a truly native iOS chat experience (SwiftUI/UIKit) as an alternative rendering backend for @chativa/rn-webview, for apps where the WebView-based widget doesn't meet the UX bar.
Background
@chativa/rn-webview (#6) currently ships a react-native-webview-based implementation: it embeds the existing web widget (@chativa/ui + @chativa/genui, loaded via the packages' existing CDN/global builds) inside a WebView and bridges events/config over postMessage. This reuses the web UI as-is and required no native re-implementation, but WebViews have known weak spots on iOS specifically — keyboard avoidance/resize timing, scroll/momentum feel, and animation smoothness can all fall short of a truly native screen.
This issue tracks the conditional fallback: only pursue this if the WebView approach proves insufficient in a real app.
Scope (to be refined when/if this is picked up)
Acceptance
- Not scheduled — this issue exists to hold the decision and scope once/if the WebView approach is found insufficient. No acceptance criteria until scoped.
Out of scope (for now)
Goal
Provide a truly native iOS chat experience (SwiftUI/UIKit) as an alternative rendering backend for
@chativa/rn-webview, for apps where the WebView-based widget doesn't meet the UX bar.Background
@chativa/rn-webview(#6) currently ships areact-native-webview-based implementation: it embeds the existing web widget (@chativa/ui+@chativa/genui, loaded via the packages' existing CDN/global builds) inside a WebView and bridges events/config overpostMessage. This reuses the web UI as-is and required no native re-implementation, but WebViews have known weak spots on iOS specifically — keyboard avoidance/resize timing, scroll/momentum feel, and animation smoothness can all fall short of a truly native screen.This issue tracks the conditional fallback: only pursue this if the WebView approach proves insufficient in a real app.
Scope (to be refined when/if this is picked up)
@chativa/rn-webview, vs. a fully separate native iOS SDK usable outside RN entirely.@chativa/core's wire protocol / connector behavior conceptually (sameChativaSettingsshape, same message/event model) even though the UI layer would be genuinely native Swift, not shared JS.Acceptance
Out of scope (for now)