Alternatives to UIApplication subclassing and method swizzling

[nostradani]

Hi,

We stumbled across your lib and integrated it into one of our apps. Unfortunately we had to deal with a few bugs (e.g. Touchpose not being displayed correctly on the keyboard in some cases), as well as some crashes, since we wanted to toggle this feature on and off while the app is running.

Within this whole process we did ended up with a complete rewrite in Swift since we introduced major changes.
Basically our version now has the following features:

• The whole component is not a subclass of UIApplication anymore. This enables other UIApplication subclasses to be used.
• No method swizzling needed anymore.
• Use of its own window. This keeps the apps view hierarchy untouched and makes it overall more independent and less invasive.

So we thought, the project might benefit from our changes. However since this basically a complete rewrite (also completely done in Swift), this might be a reason not to use it.

So would it make sense to provide a pull request with this rewrite?

[johndpope]

it makes sense to me - please share this code.

N.B. for latest xcode - the readme needs some updating for swift.
Otherwise you may get use of unresolved identifier 'QTouchposeApplication'

import Touchpose // simple enough fix.

UIApplicationMain(Process.argc, Process.unsafeArgv, NSStringFromClass(QTouchposeApplication.self), NSStringFromClass(AppDelegate.self))

[johndpope]

[toddreed]

@nostradani: First, sorry for totally ignoring your inquiry for so long. I must have missed the notification from GitHub and since I haven't done any work with the Touchposé project in a long while, I never noticed it.

Is your Swift clone of Touchposé open source? I'd be interested at looking at it to see how it's implemented and whether it's worth incorporating the techniques into Touchposé.