This blog post explores improving type safety and reducing boilerplate when communicating between iOS apps and WatchOS complications using Swift. The author introduces two Domain Specific Languages (DSLs) built with Swift's result builders. The first DSL simplifies defining data models shared between the app and complication, automatically generating the necessary Codable conformance and WatchConnectivity transfer code. The second DSL streamlines updating complications, handling the asynchronous nature of data transfer and providing compile-time checks for supported complication families. By leveraging these DSLs, the author demonstrates a cleaner, safer, and more maintainable approach to iOS/WatchOS communication, minimizing the risk of runtime errors.
Apple is open-sourcing Swift Build, the build system used to create Swift itself and related projects. This move aims to improve build performance, enable more seamless integration with other build systems, and foster community involvement in its evolution. The open-sourcing effort will happen gradually, focusing initially on the build system's core components, including the build planning framework and the driver responsible for invoking build tools. Future plans include exploring alternative build executors and potentially supporting other languages beyond Swift. This change is expected to increase transparency, encourage broader adoption, and facilitate the development of new tools and integrations by the community.
HN commenters generally expressed cautious optimism about Apple open sourcing Swift Build. Some praised the potential for improved build times and cross-platform compatibility, particularly for non-Apple platforms. Several brought up concerns about how actively Apple will maintain the open-source project and whether it will truly benefit the wider community or primarily serve Apple's internal needs. Others questioned the long-term implications, wondering if this move signals Apple's eventual shift away from Xcode. A few commenters also discussed the technical details, comparing Swift Build to other build systems like Bazel and CMake, and speculating about potential integration challenges. Some highlighted the importance of community involvement for the project's success.
Malimite is a free and open-source decompiler designed specifically for iOS and macOS applications. It aims to reconstruct the original Objective-C code from compiled Mach-O binaries, assisting in security research, software analysis, and understanding the inner workings of closed-source apps. Built using Swift, Malimite leverages a custom intermediate representation and features a modular architecture for easy extensibility and improvement. The project is actively under development and welcomes contributions from the community.
HN commenters generally express interest in Malimite's capabilities, particularly its potential for reverse engineering Swift and SwiftUI. Some highlight the difficulty of decompiling Swift and applaud any progress in this area. Others question its effectiveness compared to existing tools like Hopper, mentioning limitations in reconstructing complex control flow and higher-level language constructs. A few raise ethical concerns about the potential for misuse in piracy and intellectual property theft, while others emphasize the importance of such tools for security research and understanding closed-source software. The developer's choice to keep the tool closed-source is also a point of discussion, with some arguing for open-sourcing it to foster community development and scrutiny.
Summary of Comments ( 5 )
https://news.ycombinator.com/item?id=43066247
HN commenters generally praised the approach outlined in the article for its type safety and potential to reduce bugs in iOS/WatchOS communication. Some expressed concern about the verbosity of the generated code and suggested exploring alternative approaches like protobuf or gRPC, while acknowledging their added complexity. Others questioned the necessity of a DSL for this specific problem, suggesting that Swift's existing features might suffice with careful design. The potential benefits for larger teams and complex projects were also highlighted, where the enforced type safety could prevent subtle communication errors. One commenter pointed out the similarity to Apache Thrift. Several users appreciated the author's clear explanation and practical example.
The Hacker News post titled "DSLs for Safe iOS/WatchOS Communication" linking to an article about type-safe WatchOS communication has a modest number of comments, generating a brief discussion around the topic. Several users express appreciation for the approach outlined in the article, highlighting the benefits of type safety and compile-time checks in preventing errors when communicating between an iPhone app and its WatchOS counterpart.
One commenter points out the inherent complexity and verbosity often associated with WatchOS communication, suggesting that the DSL approach could significantly streamline the process and make it less error-prone. They emphasize that catching these types of errors at compile time is much more efficient and less disruptive than dealing with them during runtime.
Another comment builds on this by noting the frequent issues encountered with mismatched data types or message formats between the watch and phone, further reinforcing the value proposition of a type-safe solution. This commenter also subtly implies that existing solutions may not adequately address this problem.
A different commenter focuses on the elegance of using Swift's features to create a DSL. They praise how the approach leverages the language's capabilities to improve developer experience and code clarity.
There's a short thread discussing alternative approaches, including one suggesting the use of a shared library and another mentioning Google Protobuf and gRPC. While these suggestions are presented, they don't receive much engagement or further discussion.
Finally, a comment mentions the historical challenges and complexities of watch development, agreeing with the original premise of the article. This commenter expresses a positive outlook toward the proposed DSL as a potential improvement in this area.
Overall, the comments generally agree with the article's premise and express positive sentiment towards the use of DSLs for safer inter-device communication. While alternative approaches are briefly mentioned, the primary focus remains on the benefits of compile-time safety and improved developer experience afforded by the DSL. The discussion, while not extensive, provides valuable insights and perspectives on the challenges and potential solutions in this domain.