GSoC/2021/StatusReports/LucasWang
KDE Connect iOS <> Status Report & Reflections
Key Links, Locations, and People
Links:
- GSoC Project Link
- KDE Connect iOS 2021 Repository (currently separate from the KDE Connect iOS 2014 repository)
- Network Tester repository, for testing various frameworks to judge their feasibility for integration with KDE Connect iOS
People:
Posts, Docs, and Articles:
How It Started:
As of April 2021, the iOS KDE Connect application possesses several issues:
Outdated UI design and features such as optimizing for newer aspect ratios, icons, fonts, and accessibility, etc.
The app is lacking many core functionalities of KDE Connect that other currently available versions have. Since Apple has implemented many of those features into iOS since 2014, the app would now be able to use them to offer the missing functionalities.
The backend portion of the app that governs LAN network communications is currently functioning inconsistently and only under a very specific series of actions.
The goal of this proposal is to address the problems listed above with an "analysis and rewrite" process of much of the app’s current code base with the newest Apple development language and UI framework, Swift and SwiftUI. Aside from solving the immediate problems with the current app, rewriting the foundation in Swift and SwiftUI would give the codebase a strong footing to expand and adapt to future contributions. SwiftUI’s cross-platform deployment capabilities also give the possibilities for forks of the codebase for other Apple platforms such as macOS and watchOS.
As such, the initial proposal, finalized in early April, outlined the following goals and deliverables:
- A completely revamped interface of the KDE Connect iOS application written in SwiftUI and adhering to the newest iOS design language.
- Additional functions were added to the new app to match the core functionalities present on other versions of KDE Connect such as the Android version.
- A revised network communications backend.
- Documentation of the unit testing done throughout the project and, using the Android KDE Connect as a reference, document the state and progress of the iOS version.
How It's Going: Key Periods & Moments
Note: Some of these events overlap with each other, and they are also not in strictly sequential order.
May - June 7th: Discussed and re-checked project proposal with mentors (timeline, other factors such as project resources, etc.). I joined KDE's Apple Developer Group to assess the situation (KDE's Apple Developer Group thus far has only been used for creating signing certificates for Krita, another KDE project written in Qt and C++. It would appear that KDE has never had any project built with Apple frameworks before that progressed into the Signing and Testing stage, and that KDE Connect iOS 2021 would likely be the first), get similar with the system, etc. I also raised the question and potential problem of accessibility to Apple's platforms and frameworks needed to develop and contribute to this project, and floated the idea of future consideration of the MacStadium FOSS program which provides FOSS projects with a free Cloud Mac Mini. Having dealt with issues like this in software clubs in school before, I really did not want the lack of accessibility to Apple's platforms to be an obstacle for potential contributors.
June 7th - 14th: GSoC's coding period started just as I wrapped up my university spring quarter and was drowning in final projects and exams. Per previous revision with mentors, the coding period for this project will be starting roughly a week later around June 14th.
June 14th - July 7th: The first prototype of the UI/UX built completely in SwiftUI was ready for presentation at the upcoming monthly KDE Connect Development meeting. Other components of the app were also re-written in Swift, such as UserDefaults for persistent storage, cross-app data flow, etc.
July 3rd: It was discovered that the huge, breaking change between iOS 12 (which my mentor Inoki was running) and iOS 14 (which I was running) was responsible for the confusing and seemingly unexplainable difficulties that I was having getting UDP broadcast to work. iOS 14 requires developer to apply for an entitlement in order to use broadcast. I began looking into the complex Apple Developer group structure as the application would requires coordination with the KDE Admins.
July 13th: The revamped UI and the Network testing app was presented to the KDE Connect developer group at the monthly meeting. The project was met with positive feedback from the group. KDE Admins were also present so I was able to inform them of the upcoming coordination required to apply for the broadcast entitlement from Apple.
July 1st - July 20th: The first prototype of the LAN communication backend built entirely using the native Swift Network framework is functional. The tester app has an intractable selector for changing modes (UDP/TCP) and is capable of sending and receiving both messages as well as sending files via the standard system file picker and receiving files by saving them into the app's document directory to and from any IP address (including broadcasting) and using any port. I found the tester at this point to be quite similar to the command line tools of netcat, and actually started using it with netcat on my Linux and Android devices to transfer files and links.
July 27th: Despite the fact that my mentors and I were aware of the potential limitations of Apple's frameworks based on our experiences dealing with Apple's developer tools and dynamics, I wanted to experiment with the new Swift Network framework to at least see what happens. I was feeling pretty good after seeing how well the Network tester app turned out. But today, that changed, this somber but real thread on the Apple Dev Forums marked a turn in the plan. The lack of ability to start TLS on an existing TCP connection without spawning a new one is a dealbreaker for the compatibility of KDE Connect iOS with the Qt and Android versions. Maybe the Network framework can still be used in the future for a new file transfer backend? But even so, we might have spent weeks exploring a framework that we might not end up using. Priorities now are to try to bridge the 2014 Objective-C backend and see what comes out of it.
July 28th - August 11th:
August 12th - August 20th: