The main limitation of Cloud Twin lies in its range of
applicability. Applications with custom UI components, especially
those that make use of animations, can not be translated
by Cloud Twin without additional input from a user. One
such domain is mobile gaming, for which the Cloud Twin
approach is inapplicable. Thus, we envision that the primary
beneficiaries of the Cloud Twin technology would be business
users who want to access productivity-enhancing applications
on their own mobile devices. Business applications commonly
feature a standard UI structure, which Cloud Twin already
supports natively. If some customized UI components become
mainstream, the Cloud Twin framework can be extended to
support them, thus benefiting the average user.
Another drawback to Cloud Twin is that the latency of
multiple operations is not composable: the aggregate latency
is the sum of the time taken by each individual UI operation.
To optimize this inefficiency, we could batch individual UI
operations to minimize the network communication latency.
We may indeed pursue this optimization as a future work
direction. Having said that, our experiences with the reference
implementation of Cloud Twin indicate that the average
latency never becomes unreasonably high to frustrate the user.
Another potential limitation of Cloud Twin concerns how