It’d been quite a while since I last worked on my React Native plugin for indexing your app’s content. During this time, react-native-spotlight-search had become quite out of date and no longer worked with modern versions of React Native.
So, thanks to some help from fellow contributors I’ve recently published a new version that addresses all of these issues and generally tidies things up 🎉
What’s New Support for modern React Native versions Fix deprecation warnings Rebuilt the example project to use RN 0.
I’ve recently been involved with a mobile app project that required frequent public releases from a master branch that contained a mixture of complete, stable features and other features that are still under heavy development. The latter features are in no shape to be shipped to the public — so how do you keep these out of the public release but readily accessible for development? One potential solution, and one that my younger naive self might have attempted, would be to maintain a feature branch for each feature that was in active development, with a view to keeping these branches un-merged until the entire feature is complete and ready to use.
I recently published a new version of react-native-spotlight-search. Check out the changes below:
What’s New Support for the ‘keywords’ property. This allows you to improve the likelihood of your content being found by adding related keywords to the index. These keywords are not displayed to the user. Please file any bugs or feature requests over on GitHub.
I wanted to improve the functionality of an app that I’m developing by allowing its content to be indexed so that it appears in the Spotlight search on iOS. The app is developed using React Native. Although there is an extremely healthy community of third-party packages for React Native, I couldn’t find one that provided the functionality I was after.
To help plug this gap in the ecosystem, I’m happy to announce that I’ve developed a new npm module for React Native that does just that: react-native-spotlight-search.
I must admit, I’m a bit of a stickler for reading the release notes for updated apps on my iPhone. I enjoy seeing the red badge count on the App Store icon and I usually go in and check for any interesting changes in the apps that I use, even if that ends up being a bug fix or maintenance release. That’s not normal behaviour is it? Some people won’t care much either way and that’s fine too.
A few days ago I noticed that one my favourite iOS apps, Day One, had recently been renamed to “Day One Classic”. I didn’t think much of this at the time but eventually I realised why this had happened: the current version of the app was being mothballed in favour of a shiny new 2.0 version which would be released as a brand new SKU.
I don’t mind paying a premium for apps.
Recently we have been observing somewhat of a paradigm shift in the programming world. A shift from imperative to a functional way of doing things. This change has coincided with not only a different way of writing code but also a different way of architecting applications altogether. Admittedly, I was quite late in catching this train and indeed I was pretty skeptical about the real-world benefits of such an approach.