Release 0.3 Announcement

Despite the requirements express in the previous announcement road map for iOS support, I decided to work around them and deliver the first milestone. I’m proud to show the fruit of that labour and deliver support for building iOS applications with XCTest for Gradle. It’s early support, which means there are limitations imposed by the plugin. For example, the application will only execute inside the simulator running iOS 13.2. The implementation language is also limited to Objective-C. I purposefully limited the scope for this first release so I could focus on the core experience from the developer’s perspective. There are two main scenarios I wanted to cover.

The first scenario is building and launching the application from Xcode. I carefully crafted the Xcode integration to delegate the build to Gradle while allowing Xcode to launch the application inside the simulator. The experience aims to be as vanilla as possible. It means you can build via Product > Build (Cmd+B) and launch the application via the main launch button, as shown in the video below.

The second scenario is testing from Xcode. This scenario is probably the most tricky to get right. The integration allows tests to be executed via the main test button in the top left corner, from the test navigator or the side dot in the editor. You can see it in action in the video below.

For both scenarios, the integration needed to allow indexing to work as expected. Developers can jump to symbol definitions, jump to files from an #import directive and perform searches inside the symbol navigator.

Feel free to try out one of the samples. If you find any issues, please open an issue. Don’t hesitate to contact me at [email protected] if you want to help sponsor the effort. We can work together and deliver the use case that would have the highest impact on your developer productivity first.

The JNI library plugin kept improving during this release. I worked with the team behind Darklaf to showcase the JNI library plugin on their project. I identified gaps in the API resolving mostly around accessing variants, binaries and their tasks. I took this opportunity to add new APIs to allow a smoother transition.

A special thanks to Javen Wang for his help in enabling to use Kotlin as a JVM language with the JNI library plugin.

Finally, I also rolled out an entire chapter on explaining building JNI projects with Gradle and the Nokee plugins.

On the documentation front, I wrote additional chapters to explain the anatomy of Nokee plugins, building JNI projects and developing with Xcode IDE. I also wrote reference chapters for all the new plugins as well as new samples covering additional use cases raised by the community.

When I started my Gradle journey in 2012, I found the build language documentation (also known as DSL reference) precious to my learning. To honour this great resource, I wrote the automation required to generate the build language reference for all public types of the Nokee plugins.

As I take documentation very seriously, it is essential to note that I consider unclear documentation as a bug. If you encounter any issue with the documentation, please open an issue, so we can improve it for everyone.

On the testing front, I added automated tests to keep the Nokee plugins in sync with Gradle release cycles. With this new addition, we are closer to the 1.0 milestone. I notice some gaps in the testing coverage during the last development cycle. They will be closed in the next release so we can move forward with the 1.0 release!

Sometimes I don’t have enough context to make a decision that would have the most impact. For this reason, I like working with teams to help drive the requirements forward. The key point is about gathering information to make clear technical decisions. I started to create poll issues that ask open-ended questions for everyone to participate. The result of those polls will help drive the Nokee plugins forward with features that you care about. I scattered links to the polls across the documentation contextualize them.

Feel completely free to provide your opinion on each one of them. I will be using those issues as guidelines for what to work on next. For this reason, specific and tangible use cases are the key point I’m looking for.

I’m scheduling improvements to toolchain support, in particular, the toolchain selection for the next release. This work is a fundamental feature that will help the cross-compiling stories with Gradle. It will be beneficial for iOS support as well as open opportunities for native Android support. It’s also essential to support dependencies and iOS libraries. CocoaPods is a must for the success of the iOS development support in Gradle. Luckily, the flexibility of Gradle will enable all these features over the next few releases of the Nokee plugins.

Don’t hesitate to leave a comment below or ping me on the Gradle community Slack. If you want to work with me and drive the iOS support for Gradle forward with your team, send me an email at [email protected].