Something is off? Something doesn’t sound right? Something doesn’t look right!
That’s it, it’s the new name and App icon. Yes, Yeti still remains our internal codename however, since this is the first Beta build, I couldn’t think of a better time to finally reveal the actual product name we’re going with: Elytra.
There’s also a new domain name. An
.app domain. I’ve been waiting to acquire this domain so I can finally release the Beta.
Well, here’s what’s new in the first Beta;
- Dark Theme for iPhones & iPads
- Black Theme for iPhone X.
- Serif type (Using Georgia at the moment, please email me your font suggestions).
- Improved Memory management.
- Lowered disk usage (and therefore lower power consumption) when a post has lots and lots of images.
- Image galleries are now accessible including controls.
- Improved Quotes design.
- Improved code blocks rendering.
- Improved text rendering performance.
- Improved “Add To Elytra” (previously, “Add to Yeti”) share extension.
- Moved the Article Helper interface to the right edge on iPads. It moves to the left for RTL idioms.
- Galleries with images with no height information are now rendered correctly.
- Galleries with more images than what can be fit horizontally (page control) are now rendered as groups of 5 photos per control.
- Fixes unread pull-to-refresh crash.
- The Title & author text is now aligned correctly with the rest of the text in the article interface.
- Fixed the “Add to Elytra” (previously, “Add to Yeti”) share sheet extension crashes.
When working on some features and fixing some bugs, I ended up running into a lot of UIKit bugs. Following are some of the known issues Elytra will present which we have to depend on Apple to fix:
- When using a dark theme, the navigation bars will misbehave and present a lot of unexpected states and behaviours.
- When searching inside an article, the highlighted area is often mis-positioned to the left or right (this depends if you’re using a LTR or RTL idiom) however, scrolling up or down a little positions this highlight correctly.
The final epoch has been rung.
- Folders support
- Added GIF and webP support
- Improves lists rendering
- Blockquotes are now rendered more scemantically
- Added support for citations
- Added support for mark elements to highlight text in paragraphs and blockqotes
- Fixes footlinks jumping to the wrong section
- Fixes a crash when an article has a lot of content. Like, over 10000 words!
- Attributions page is now fully functional.
- Fixed search for Feeds
- Fixed search for articles
The final alpha build is out. I look forward to hearing from you lot on the new improvements. As I now slowly work towards polishing the app up and work on the macOS app, I look forward to your criticism, feature requests and love/hate emails. Have a fun weekend, and enjoy reading.
I suppose I underestimated myself when I wrote this.
- Authors: Supported publishers have been enhanced with author support. This is currently limited to http://macstories.net and http://sixcolors.com. If you’d like to see support added for your favourite publisher, get in touch. You can now view all posts by a single author and tap on the ⦿ to view information about that author. Author bios in the article interface has been scrapped.
- Push Notifications: Push notifications based on WebSub are finally here. At the moment, only this blog supports Push notifications. As more and more publishers begin supporting WebSub, this list will expand, and automatically. Just find the bell icon in the Feed Interface. If it isn’t there, the publisher most likely doesn’t support WebSub at the moment and therefore, push notifications won’t be available.
- Filters: Maybe it’s Game of Thrones release time and you’d like to completely avoid all spoilers. You can setup keywords under Settings > Filters and these will apply throughout Yeti. Once you add new filters or remove existing ones, don’t forget to refresh your feeds.
Fixes & Improvements
- Improved accessibility labels for the “Mark all read” button making it more descriptive.
- Fixed rendering of <aside> tags from certain publishers.
- Some articles wouldn’t display embedded images. This has been fixed.
- Improved quote rendering on iPads.
- Fixed a rare crash that would occur on the iPad Pros (2017) when marking an article as unread.
- Improved sync speed for bookmarks.
Also, major news: this is the penultimate alpha build of Yeti. After the next build, I’ll be starting work on the Beta feature set (which is small, but contains a larger locale set for testing on my end). Once the alpha run is over, I’ll be freezing the spec on my end for the server side parser.
This is going to enable me to enable publishers to add new meta tags to their article pages to customise rendering aspects inside Yeti. This is the major component of the beta run. Which means, there will be fewer beta builds, once every 15 days or so.
Until then, enjoy the alpha. Have fun reading!
We all hate delays. Especially when it comes to airplanes and commercial flights. But this is alpha-grade software. Today is Friday. You’re most likely not waiting for a new build notification to pop up on your screen.
But I do have a very good reason for this. Let me break it down:
I’m not even sure why this turned out to be this tricky to implement. Bookmarks are great when they are online on some server your phone connects to. But Yeti promised (actually, I did) to make them available offline. This is easy when it’s only a single device. Multiple devices is very tricky though and I did not want to spend time on a full fledged sync service.
But, as always, I have it figured out. Mostly. I have a lot of testing pending on my end (automated and manual). Once those are through, the build will be a third ready.
2. Author Bios
Why aren’t more RSS readers doing this? It may involve manual work (as in the case of Yeti) or some person smarter than I can figure out a contextual way to grab this information off the publisher’s website. Well, Yeti doesn’t have the time to wait for some popular app to do it. You’ll be able to browse articles by that particular author as well as read about the author towards the end of the article (if you enable it under settings, it’ll be off by default).
3. Push Notifications
I spoke about Realtime RSS here and I’m glad it all worked out to be simpler than I aniticipated. So to bring these advantages to you, I’m working out the interface and potential “fine grain” settings that you can tweak to get notifications about new articles from your favourite publishers.
So the app itself isn’t delayed. It’s still on track according to my tracker (assuming it’s functioning correctly). What is delayed is the week 4 release. So week 5 will have things from both of these weeks. I moved things around so this will be a big release and I get more time to implement things a little better and make sure everything works smoothly for my wonderful alpha group (*cough* unlike a certain release cycle *cough*).
Build 40 just went to all Alpha testers. Here’s the changelog.
New & Improved
- Unread feed. All your unread articles in one place.
- Articles will now show unread states
- Changed article lists layout to accommodate better for accessibility preferences.
- Improved handling for accessibility content size preferences
- Improved RTL rendering of text
- List rendering in some cases where a single item had multiple components in it.
- Images & Galleries no longer overflow bounds of iPhone screens.
What you won’t see
I’ve added preliminary support for the Subscriber part of the WebSub1 protocol to the backend. This vastly improves how I fetch new articles. Currently, it’s only enabled for this blog. New publishers, you add to the service, which advertise their hubs will be automatically added. For all existing publishers, I’ll manually check and verify.
- I talk more about this and the upcoming near real-time capabilities of Yeti here. ↩
Yes, you read that right. Thanks to the WebSub spec, Realtime RSS is not only possible, but wildly scaleable if implemented correctly. Yeti is making an attempt at that.
It will not only enable Yeti to:
- fetch posts in realtime from the publisher (your favourite websites)
- update content stores soon after posts are published
- spend less resources on polling publisher websites
- enable you to subscribe to your favourite publishers
- receive near-realtime notifications1 from these publishers
- have the app update itself in the background when the system determines so
The implications of the above are grand.
If the above holds true, which by means of this post: I am looking for feedback on the above, I not only save money, but enable you (and myself) to get real time notifications from publications which really matter to me. As since Yeti will be paid there won’t be any add-on cost you’ll have to pay to get this. It’s all part of the package.
I look forward to hearing your thoughts on the matter in the comments section below.
- You can choose which publishers to receive notifications from, just like you would on Youtube. ↩
Emily Waite writing for Wired.com
The difference between getting news from an RSS reader and getting it from Facebook or Twitter or Nuzzel or Apple News is a bit like the difference between a Vegas buffet and an a la carte menu. In either case, you decide what you actually want to consume. But the buffet gives you a whole world of options you otherwise might never have seen.
That’s an excellent analogy.
RSS readers obviously have their own shortcomings as well. The firehose approach can easily overwhelm, especially when multiple outlets all publish the same news at the same time.
So introducing filters in Yeti was definitely a good idea.
And some more…
The readers all have settings to help cope with these issues to varying degrees, where possible; it’s just a matter of how many hours you want to spend shaping your RSS bonsai.
And thus Yeti’s approach to get you started with the basics, yet empower you with power tools.
I believe I’m doing the right thing here. Given how much attention this post has garnered over the last couple of hours, I think the timing is just right for Yeti. I guess I’ll just have to go right into the 6th gear and ramp up production.
Another Friday, another alpha release. This is a House-keeping build required for the upcoming single feeds: Unread and Bookmarks.
- Image settings now take effect. If the source does not provide alternate image sizes, the default url is used (which could be a big image).
- Removing feeds
- Searching for an article has been optimised to run smoothly on older devices.
- When feeds are loaded on app launch, it’ll load the full batch, and then onwards, only load new changes. This largely improves caching and networking performance.
- The API has also been updated to not return responses if the local cache matches the server response.
- Tweet rendering (only works if Tweets were embedded and not quoted)
- Feed listings now update when you move to the next or previous article using the accessibility view. This also enables endless scroll on iPads (maybe even on iPhones, but I haven’t tested it)
- Image views and Gallery views have been reimplemented to be faster for rendering, more performant and use less memory.
- Improved text rendering for the article title & author in the article view. It should now scale gracefully with dynamic type.
- The above change has also been made in the Feed view for individual cells.
- All layout rendering issues in the Article renderer have been resolved. This includes stupid Xcode warnings and the like.
A) Quotes sometimes render with extra height. This is a known issue.
B) Formatted code blocks don’t scroll horizontally in the same line. This is a known issue.
- Opening links externally is now partially implemented. This may still crash in some situations.
- Sharing an article now adds a “space” between the title and URL. This will be in place until Apple resolves the bug and restores the correct behaviour.
I hope you enjoy reading over the weekend. Have a good one. ✌🏼
If you’re familiar with the NATO phonetic alphabet, you’ve already postulated what the post is about. Keeping things in fashion, allow me to burst out of my shell of excitement and say, Project “Yeti” is finally real.
Yes, it has always been real. Real for me. But now, with today’s alpha release, it’s real-er as more people are onboard. So to everyone who is, you probably are already testing things it, playing around with it, tinkering it, breaking it, and what have you. So have a blast using it, just as I have working on it up to this point.
I did manage to sneak in “one-more-thing” into the alpha release which was planned for way later. “Add to Yeti” from the share extension. It isn’t the most perfect implementation, but it is usable. It’ll enable you to get off the ground more quickly.
If you’re looking to import your existing stuff into Yeti, well, sorry. But that didn’t make into this build as I wasn’t able to thoroughly test it. So if you have your OPML file ready, feel free to email it to me as it’ll aid me test the system better.
I’ll spare you with the technical details in this post. A year’s worth of work has finally taken shape of an actual product. I’ll allow myself to enjoy that feeling, while you enjoy the app (or utterly hate it…)
Once again, let’s begin with the abstract confusing title.
But it’s a real one. Here’s some proof.
As you can see, that’s an actual commit. Well, allow me to explain why this exists in the first place.
When you going through a lot of items in a feed, you may find yourself requiring to quickly move between those items or within an item itself. This is particular useful when you’re researching something. The search (which I talk about here) feature ties into this specific bit.
So what is previous next up and down? Think about it in terms of the article. So what you get is:
- Previous article
- Next article
- Beginning of article
- End of article
So now you never have to leave the reading interface and can go for a reading spree if that’s your thing.