DEV Community: Justin Mancinelli

You Need a Rubric (when evaluating multiplatform solutions)

Justin Mancinelli — Wed, 15 Apr 2020 17:01:08 +0000

Last week, I spoke to an audience about evaluating multiplatform solutions. Spoiler: you need a rubric, and the criteria you pick will be heavily context-dependent.

Coincidentally, I got a comment on my Lead Dev NYC 2019 talk a few days later, bringing up 5 criteria that leads him to choose React Native.

My response became more of an article, so here we are: his comment, and my response

Kotlin multiplatform is promising, but when comparing stacks, these key factors rarely get mentioned:
1) does it allow for a shared end to end testing and continuous integration setup between platforms?
2) does it have feature parity by design?
3) can code be shared between web and mobile?
4) availability of experienced developers?
5) shared pull requests between ios, android, and web (and thus converging knowledge and coding standards)?

Kotlin MP will likely never check these boxes, which people should be aware of before deciding. E.g. React Native is quite powerful when looking at the overall benefits and teams like shopify seem to agree.

Thanks for raising these questions.

Before anyone asks questions, they need to know if it is relevant to their business. And, when they ask questions, they need to know how important each one is to their business. There are world-class engineers at Nubank, Shopify, and Square and each of them made different code sharing decisions (Flutter, React Native, and Kotlin Multiplatform respectively). And let’s not forget the recent examples of Airbnb and Udacity abandoning React Native after years of investment in using it. Since every business is different, there is no one-size-fits-all evaluation criteria.

To answer your questions:

Depends, because the focus is on sharing business logic, not UI, the shared testing is focused on the business logic. If you are building an SDK without UI concerns, then yes, you can E2E test the product under test. If you are building apps that share business logic with KMP, then no, but you can share common tests.
No, it has optional sharing by design. This allows for greater feature alignment while reducing re-write risk in existing code, and easier, purposeful platform specific integration if the product calls for it. (See my thoughts related to feature-alignment as a goal)
Yes, Quizlet is doing exactly that. KotlinJS came before Kotlin/Native and they are now both under the Kotlin Multiplatform umbrella.
Depends what experience you are looking for. Since React Native has been out longer, there is a larger pool of people with React Native experience. However, React Native is different enough from both React Web and Native Mobile, that both experienced react web devs and native mobile devs have issues with it. And people who have a few years experience with React Native often build within the confines of React Native and libraries available which gives them trouble when the product requires more native platform integration or platform specific look and feel. As for KMP, Kotlin experience is easy to come by and the experience needed to integrate the generated framework into an iOS project is easy to come by as well. The difficulties are in the details which is more about good software development, rather than experience with each technology.
Yes, Touchlab and other companies adopting KMP recommend shared PRs and ways to enable that like monorepos, bringing together Android and iOS teams into Mobile teams, building tools like our Kotlin Xcode plugin, and shared coding standards, especially around architecture and API style, to ease the transition to all platforms working together.

I wouldn’t say “likely never check these boxes”. For 1, the open source community is growing and there are already several concepts around sharing UI with KMP as well. For 2, similar answer as 1, you can already build full react web apps in Kotlin and the community is looking at ways to share everything for feature parity across all supported platforms.

Again, not everyone’s questions/criteria will be the same and the weight given to each will be different too. The people choosing KMP put more weight on its optionality, native interop, use of Kotlin, and deference to the platform UI and ecosystems. (See my recent webinar on this subject)

Lastly, since my talk, React Native has continued down the path of becoming “more native” with the introduction of JSI and Turbo Modules. Though, so far, those are more native in the C++ sense, rather than the Kotlin/Swift sense and that will bring issues related to what DropBox encountered. But again, there’s no one-size-fits-all criteria.

For more of my thoughts on this topic, please watch my 20 minute webinar

What do you think the dev.to feed algorithm should be?

Justin Mancinelli — Thu, 23 Jan 2020 15:42:36 +0000

I dove into the code to find out what it is now.

The Dev.to Feed Algorithm 🤖

Justin Mancinelli ・ Jan 23 '20 ・ 7 min read

#meta #rails #beginners #webdev

It's been changed a few times in the past.

What do you think of it? Do you have suggestions for what would work better for you?

The Dev.to Feed Algorithm 🤖

Justin Mancinelli — Thu, 23 Jan 2020 15:19:24 +0000

TL;DR👇

I used to develop apps. I still do, but I used to, too

Back in 2007/2008, I learned Ruby on Rails and developed two prototype sites that didn't end up in production. Since then, I did extensive work on non-Ruby, non-Rails server applications and learned enough about Android and iOS apps to manage the development of mobile apps in my current role.

I never touched Ruby on Rails again...until @anshbansal asked a question that I had asked myself a few times before.

What is the algorithm for dev.to's feed?

Aseem Bansal ・ Jan 12 '20 ・ 1 min read

#discuss #help

The following is my deep dive into the dev.to codebase to answer this question. There are probably a few things wrong, please point them out in the comments so I can correct them. Thank you.

Start at the beginning

And it doesn't get much earlier than the root route
root "stories#index"

Taking control

Rails follows a Model View Controller (MVC) architecture. When you ask dev.to to show you the root page, it will ask the stories controller to run the index action.

What we see there is it sets up a bunch of state then renders the articles/index template
render template: "articles/index"

Show me the stories

If you inspect your dev.to home screen, you'll notice all the articles/stories are listed within an articles-list div. You can find it in the articles/index view as expected.

And here's where we start to see how the feed is populated.

OK, first show me the featured story

The first story in the article list is a featured story.

The algorithm to get the featured story for a logged in user comes from the stories controller and the articles/index view. I've simplified it by substituting some variables and reorganizing some statements.

@stories = Article.published.limited_column_select.page(1).per(35)
@stories = @stories.
  where("score > ? OR featured = ?", 9, true).
  order("hotness_score DESC")
offset = [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
          1, 1, 1, 1, 2, 2, 2, 3, 3, 4, 
          5, 6, 7, 8, 9, 10, 11].sample # random offset, weighted more towards zero
@stories = @stories.offset(offset)

@featured_story = @stories.where.not(main_image: nil).first&.decorate || Article.new

In English:

Fetch a collection of stories that score above 9 or are featured

Order them, starting with the "hottest" one

Randomly skip the first 0 to 11 stories, weighted more towards 0

The featured story is the first story that has a main image

Leaving how score, featured, and hotness are determined as an exercise for the reader

Notice the featured article has nothing to do with which people, organizations, or tags you follow.

Now show me the rest of the stories?

After rendering the featured story, the article/index view creates a substories div and then renders the stories/main_stories_feed partial
<%= render "stories/main_stories_feed" %>

These are not the divs you are looking for

I was scratching my head while reading through the _main_stories_feed partial

It populates the data attributes of a new-articles-object div and a home-articles-object div, then a bunch of other divs that have no contents. And the divs I do see when inspecting the home screen have the single-article single-article-small-pic class, but don't look like what's in this file.

Evil action-at-a-distance like this can only mean one thing: JavaScript

Nobody expects the Spanish Inquisition

Searching the repo for new-articles-object and home-articles-object, we find them both in initializeFetchFollowed Articles, called very early when a page is initialized.

And there is a lot of logic here which I did not expect.

The new stories are not the old stories

The stories controller populated the @stories collection used for the for the featured story. It is also used to populate the the data attributes of the home-articles-object div. But that comes next, not now.

Instead, The first stories we see after the feature article are, populated from a query directly in the view.

@new_stories = Article.published.
  where("published_at > ? AND score > ?", rand(2..6).hours.ago, -15).
  limited_column_select.
  order("published_at DESC").
  limit(rand(15..80))

In English:

Fetch a collection of stories that have been published some time in the last 2 to 6 hours and score above -15

Order them by most recent first

Return the first 15 to 80 of them

Then the JavaScript function insertNewArticles takes over:

articlesJSON.forEach(function(article){
      var articlePoints = 0
      var containsUserID = findOne([article.user_id], user.followed_user_ids || [])
      var containsOrganizationID = findOne([article.organization_id], user.followed_organization_ids || [])
      var intersectedTags = intersect_arrays(user.followed_tag_names, article.cached_tag_list_array)
      var followedPoints = 1
      var experienceDifference = Math.abs(article['experience_level_rating'] - user.experience_level || 5)
      var containsPreferredLanguage = findOne([article.language || 'en'], user.preferred_languages_array || ['en']);
      JSON.parse(user.followed_tags).map(function(tag) {
        if (intersectedTags.includes(tag.name)) {
          followedPoints = followedPoints + tag.points
        }
      })
      articlePoints = articlePoints + (followedPoints*2) + article.positive_reactions_count
      if (containsUserID || article.user_id === user.id) {
        articlePoints = articlePoints + 16
      }
      if (containsOrganizationID) {
        articlePoints = articlePoints + 16
      }
      if (containsPreferredLanguage) {
        articlePoints = articlePoints + 1
      } else {
        articlePoints = articlePoints - 10
      }
      var rand = Math.random();
      if (rand < 0.3) {
        articlePoints = articlePoints + 3
      } else if (rand < 0.6) {
        articlePoints = articlePoints + 6
      }
      articlePoints = articlePoints - (experienceDifference/2);
      article['points'] = articlePoints
    });
    var sortedArticles = articlesJSON.sort(function(a, b) {
      return b.points - a.points;
    });
    sortedArticles.forEach(function(article){
      var parent = insertPlace.parentNode;
      if ( article.points > 12 && !document.getElementById("article-link-"+article.id) ) {
        insertArticle(article,parent,insertPlace);
      }
    });

In English:

Give each article 0 points to start off with

Sum the weight of each tag (which can also be negative) the user follows and this article is tagged with, then double it

Now add to that, the number of positive reactions the article currently has

If the user follows the article's author, or is the articles author, add 16 points

If the user follows the article's organization, add 16 points

If the article is written in the user's language, add 1 point, otherwise, subtract 10 points

Randomly (with equal chance) give the article an extra 0, 3, or 6 points.

Subtract half the difference of this articles experience level vs the user's experience

Order the articles by most points first

If the article has more than 12 points, show it to the user

What about the rest?

The next batch of initialized articles come from the same batch we got the featured article from and processed by a new (but familiar) algorithm in insertTopArticles.

When you get to the bottom of that list, articles are populated from an algoliasearch index of ordered articles. The definition of that index is found in the Article model.

Finally, scrolling kicks in which you can find in initScrolling.js.erb and populates more articles from the algoliasearch index.

Leaving the details of these as an exercise for the reader

TL;DR

For the first article in the list:

Fetch a collection of stories that score above 9 or are featured

Order them, starting with the "hottest" one

Randomly skip the first 0 to 11 stories, weighted more towards 0

The featured story is the first story that has a main image

For the next batch of articles:

Fetch a collection of stories that have been published some time in the last 2 to 6 hours and score above -15

Order them by most recent first

Return the first 15 to 80 of them

Give each article 0 points to start off with

Sum the weight of each tag (which can also be negative) the user follows and this article is tagged with, then double it

Now add to that, the number of positive reactions the article currently has

If the user follows the article's author, or is the articles author, add 16 points

If the user follows the article's organization, add 16 points

If the article is written in the user's language, add 1 point, otherwise, subtract 10 points

Randomly (with equal chance) give the article an extra 0, 3, or 6 points.

Subtract half the difference of this articles experience level vs the user's experience

Order the articles by most points first

If the article has more than 12 points, show it to the user

If you've scrolled passed all of those,

Using the same collection the featured article came from

Process with a similar but different algorithm as the previous batch

And, finally

All articles ordered by hotness

Closing remarks

This could change at any time. For example, on 2019-09-19, @ben merged a PR to add more variation to home feed. All links to github are to the commit that I saw which was in master at the time of writing but, by the time you read this, master has probably moved on.

Don't sacrifice user experience for a better developer experience

Justin Mancinelli — Mon, 13 Jan 2020 14:33:44 +0000

As a mobile developer, it is understandable to focus on platform fragmentation and writing UI twice as pain points.

As a web developer, it is understandable to try to leverage your web expertise so that developing for a new platform is less painful.

Love this slide from Ellen Shapiro's Talk¹

From a user perspective, fragmentation is what makes different platforms unique. Games can get away with having the same UI across all platforms because users expect games to be their own world, not confined to platform conventions. And, although platform UI conventions have seen convergence (e.g. material design includes guidance on Bottom navigation now), they are still different. When non-game apps don’t conform, they are perceived as a Linux app running on Windows, or an iOS app running on Android, or somewhere in the uncanny valley.

Apps shouldn’t conform 100% because they have different branding, use cases, flows, audiences, etc. They require deliberate design both for what elements are shared and what diverge. That is where native UIs become an asset. Yes, there is more for developers to think about and to deal with. Yes, it’s a pain for developers to keep things updated and meet user expectations of different OSs and versions of OSs. But, you can also make the best UI possible for each platform.

Apple, Google, and Microsoft invest a lot in the standard UI tooling, libraries, and widgets so that when you use an app on iOS, Android, MacOS, or Windows, there is a certain consistency of quality and experience, and, when you develop for them, you are using the best tool for the job.

It’s possible to make a terrible app no matter what tools you use. Flutter and React Native may make it easier to make a decent app across platforms, but you need to go native to build an excellent app across platforms.

The history of write-once-run-anywhere and shared UI is a volatile one. The history of shared code, below the UI, is a successful one. Kotlin Multiplatform focuses on shared code below the UI and lets you use the platform provided tooling to their fullest extent. That makes it doubly less risky: less risk of making a poor UI and less risk of being locked into a 3rd party (for now, Flutter is at best 2nd party).

KMP is still in the relatively early phases, @touchlab is an innovator on the adoption curve and anyone putting KMP into production right now is an early adopter. 2020 may be the start of the early majority phase with iOS support in Android Studio and multithreaded coroutines in Kotlin Native.

Just because you can share UI, doesn't mean you should

Coming back to the UI topic. There are already attempts at shared UI libraries built on KMP, and there will be more and there will be ones that gain popularity and maturity. The fact that you can already write UIKit code with Kotlin makes that easier.

But again, be careful, be deliberate, know your users. Just because you can share UI, doesn't mean you should. Android, iOS and Web are very different. But we learned from Catalyst that users even notice the difference between iPad and Mac. The outcry stopped one prominent developer from releasing a quick port to Mac and it became clear that Apple should have provided better guidance on the UI differences expected.

Lastly, remember that Apple and Google put a lot of money, time, and effort into their platforms. They want people to buy their devices which means good UX (user experrience) and they need developers to build more apps for each platform which means good DX (developer experience). Jetpack Compose is maturing, Swift UI is maturing. Kotlin Multiplatform doesn't stop you from investing in either. Jetpack Compose is already Kotlin First, and SwiftUI+KMP might just be an ideal developer experience for making ideal user experiences on iOS, too.

1. I walk the line

Thoughts, Tips, and Observations about speaking at conferences: a thread from Corey Qinn

Justin Mancinelli — Sun, 12 Jan 2020 03:24:26 +0000

I just finished reading this 100+ long, entertaining, and amazing thread:

Corey Quinn

@quinnypig

Okay. For every retweet this gets (TO A POINT!) I'll add a thought / tip / observation about speaking at conferences.

19:02 PM - 10 Jan 2020

Posting here in case you haven't seen it. Highly recommended. If you've never thought about speaking, it may inspire you. If you have just started (like me), you'll learn a lot. If you are a veteran, I suspect there's interesting tidbits in there for you, too.

A tale of checksums and client-side security🙀

Justin Mancinelli — Mon, 06 Jan 2020 14:23:08 +0000

Chapter 1 - When you come to a fork in the road, take it

^{📝 As once said by Yogi Berra}

I was wandering through the intranet at a previous job looking at what other similar teams were up to and came across a link to their product's test environment (open to the internet). Unfortunately, it was password protected:

URL redacted -- it points to a 404 now

At first glance, I thought it was basic authentication because of the alert window. On second glance, it was definitely a window.prompt() box. And the code looked like this:

function promptUserForPassword(pass) {
  if (jesChecksum(pass) != 9887) {
    pass = prompt("Please enter the passkey","");

    if (pass == null) {
      document.location.href = defaultHref;
    } else {
      verifyPassword(pass);
    }
  } else {
    successfulLogin(pass);
  }
}

Since this is client-side authentication, I could just look into successfulLogin and force success without any password. But what's the fun in that?

It was much for fun to see if I could get jesChecksum(pass) to equal 9887. The first hint that it was probably fairly easy is that the function hints the algorithm is a checksum.

Chapter 2 - Checksums are unsuitable for any kind of security work

^{📝 As pointed out by Jeff Atwood}

First, let's consult Wikipedia to find out what a checksum is:

A checksum or hash sum is a small-size datum from a block of digital data for the purpose of detecting errors which may have been introduced during its transmission or storage. By themselves checksums are often used to verify data integrity, but should not be relied upon to also verify data authenticity.

It's interesting that another name is "hash sum" but, it's very clear from the above quote, the functions you use to hash your passwords aren't the same as a checksum.

So what's a hash function? Back to Wikipedia:

A hash function is any function that can be used to map digital data of arbitrary size to digital data of fixed size.

Ok, then checksums are a kind of hash function. There are lots of different kinds of hash functions. They can do lots of different processing to generate the hash. The resulting hash can be of different sizes. Most importantly, different hash functions have different properties: speed, reversibility, number of collisions...

Collisions and speed are super important for the hashing functions that back perl hashes, java hashmaps, python dictionaries, and javascript objects. Too slow, and the initial O(1) lookup is slow; too many collisions, and lookups will need to O(n) traverse the list in the bucket.

What about those password hashes? Enter cryptographic hash functions

Unlike checksums and the hash functions used for associative arrays, Wikipedia tells us:

The ideal cryptographic hash function has four main properties:

it is easy to compute the hash value for any given message

it is infeasible to generate a message from its hash

it is infeasible to modify a message without changing the hash (avalanche effect)

it is infeasible to find two different messages with the same hash.

#1 and #2 mean it is much faster to figure out the hash than it is to figure out what the hash came from.

#3 and #4 make it really hard to triangulate or brute force what the hash came from.

Unlike cryptographic hashes, it's often easy to find checksum collisions, even for more complex algorithms like CRCs (PDF - Reversing CRC).

Chapter 3 - My crime is that of curiosity

^{📝 From The Conscience of a Hacker}

How can jesChecksum(pass) equal 9887? Here it is:

function jesChecksum(str) {
  var primes = [ 2, 3, 5, 7,11,
                13,17,19,23,29,
                31,37,41,43,47,
                53,59,61,67,71,
                73,79,83,89,97];
  var rtn = 0;

  for (i = 0; i < (str.length); i++) {
    tmp = str.charCodeAt(i) * primes[i];
    rtn = rtn + tmp;
  }

  return rtn;
}

It may look difficult to solve this without lots of trial and error. After staring at it a bit longer, you'll notice it just takes each letter of the string passed in, multiplies it by a prime at the same position, then adds them all up.

How does that make things easier? If the string is 1 character, it just needs to have the code 4943.5.

The good news is Unicode does have character codes that high (4943 is ፏ, 4944 is ፐ). The bad news is they are all integers so we can't get by with a one character password.

If the string is 2 characters, we just need to solve a nice linear equation 2x + 3y = 9887 where x will be the first character of the string, and y the second character. The Integer Diophantine Equations Solver tells us there are over 500 integer-pairs that will open the lock (although, some don't correspond to existing unicode characters).

100 is a nice number so I converted each to hex, then looked up each unicode character (Ī, ఙ):

x100 = 298 = 0x12A => Ī
y100 = 3097 = 0xC19 => ఙ

I've seeded the below RunKit example with that and you can change it to try others.


    
function jesChecksum(str) {
  var primes = [ 2, 3, 5, 7,11,
                13,17,19,23,29,
                31,37,41,43,47,
                53,59,61,67,71,
                73,79,83,89,97];
  var rtn = 0;

for (i = 0; i < (str.length); i++) {
    tmp = str.charCodeAt(i) * primes[i];
    rtn = rtn + tmp;
  }

return rtn;
}

// seeded with U+012A and U+0C19
jesChecksum("Īఙ") // = 9887

Epilogue - Nothing is actually impenetrable

^{📝 Elliot says this in eps1.4_3xpl0its.wmv}

I used to think the stuff Elliot does in Mr Robot was entirely fictional. Then I read this thread:

// Detect dark theme var iframe = document.getElementById('tweet-973725064507068416-255'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=973725064507068416&theme=dark" }

The thing is, there are always security holes whether in the physical world or the software world. And software security is harder than physical security because it obeys different rules.

There are benefits to processing some security rules or other server-required constraints on the client-side but any actual security should be done on the server. The biggest problem with the test environment I got into was it relied entirely on client side validation for security. I could have just bypassed it. It was't even obfuscated, and, though that won't stop someone who really wants to get in, it probably would have stopped me. By the way, adding obscurity on top of security is good practice, just don't let obscurity be your only security.

Another big problem with the test site was rolling its own "hashing" function. Security is hard. Secure algorithms are hard. Experts created MD5 as a cryptographic hash function but that got compromised just a few years later.

Lastly, even if you do choose the right tool for the job, something may go terribly wrong if you don't use it correctly:

Explain XKCD has amazing details on this one

Quizlet Adopting Kotlin Multiplatform

Justin Mancinelli — Wed, 18 Dec 2019 21:29:27 +0000

@kpgalligan shared Quizlet's Medium post, Shared Code at Quizlet: Deciding on Kotlin Multiplatform, the day it dropped.

I then discovered @ankushg had already let that cat out of the bag nearly 2 months earlier:

// Detect dark theme var iframe = document.getElementById('tweet-1180626868174647296-253'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1180626868174647296&theme=dark" }

It's a super interesting read because it tells the story of trying to share with JavaScript first, thinking about sharing with C++, then finally deciding on Kotlin Multiplatform.

I'm a fan of the term "platform citizen" but it's probably a coincidence that they used it too:

Kotlin Multiplatform promises the ability to write code in Kotlin and have it run as a first-class citizen on each platform.

But here are my favorite takeaways:

General

For many businesses, requiring internet connectivity for core product features might be a very reasonable requirement! Quizlet however has a particularly strong affinity for mobile users with limited Internet access.
...
By focusing our shared code efforts on code based around state management and control flow, we saved our engineering team countless person-hours with minimal time spent on cross-platform threading or concurrency concerns.

JavaScript

these issues resulted in an ecosystem where frontend web developers might have felt comfortable writing shared code, but mobile developers certainly did not feel comfortable consuming it.
...
We were able to write our most critical business logic in one place, ship it across multiple platforms, and unblock our resource-constrained native mobile teams. Most importantly, we were able to do this without committing to writing our entire client with the same framework.

Kotlin Multiplatform

even our frontend web engineers found themselves impressed by Kotlin.
...
In early 2019, Quizlet migrated all of our shared code over to Kotlin Multiplatform, and we are using it in production to serve over 50 million monthly active users.

Please read the whole thing: Shared Code at Quizlet: Deciding on Kotlin Multiplatform

And checkout their mention in the KotlinConf Keynote alongside a several other great examples of Kotlin Multiplatform in production

Skip to 13:00 for Mobile Multiplatform mentions

How do you know when a technology is ready?

Justin Mancinelli — Wed, 18 Dec 2019 15:43:03 +0000

Technology is fast-moving. It seems there's something new to try everyday.

Trying something out yourself is one thing. Piloting technology at a company is another. And putting it into production is a big deal.

How do you know when a technology is ready for you and your company's time and effort?

This general question inspired by by a more specific one which started life as a twitter poll.

Kotlin Multiplatform: Ready or Not?

Justin Mancinelli — Wed, 18 Dec 2019 15:40:32 +0000

The results of my twitter poll are in:

Liquid error: internal

What will it take to move from "too early" to "ready"?

If you have started, what have you built and what successes and challenges have you experienced?

If you haven't, what's holding you back?

This question also inspired a more general one: How do you know when a technology is ready?

Paper as a Platform

Justin Mancinelli — Fri, 06 Dec 2019 19:19:52 +0000

The past couple of weeks, I've been printing articles from blogs, newspaper sites, magazine sites, and a few course description pages from a few colleges.

And now it just hit me how great some of the experiences have been and how poor others have been. Images, margins, advertising, footers, etc. Some pages remove, resize, and re-emphasize exactly the right things for it to look great on the printed page.

Most of the time I'm thinking about digital platforms: web, mobile, desktop (the odd kiosk now and again). But anyone could choose to print from a website, moving it from the digital platform to the paper platform.

Discuss

How do you approach designing and implementing for paper UX?

Why did you (or not) choose cross-platform mobile technology?

Justin Mancinelli — Thu, 05 Dec 2019 15:30:09 +0000

Egor Tolstoy

@igrekde

@jetbrains In the last couple of months we’ve interviewed dozens of mobile developers. We wanted to understand why they choose (or don’t) to use some cross-platform technology, what are their goals, intentions and pains. And that influenced a lot how we see Mobile Multiplatform today.

13:59 PM - 05 Dec 2019

This is an important discussion, not just for the people making the technology, but the people evaluating them too. Business context matters; team membership, recruiting and retention matter; technology, language, architecture, matters; and the community matters too. What else? And what matters to you?

Craigslist Launches Mobile App

Justin Mancinelli — Thu, 05 Dec 2019 13:56:13 +0000

Woke up this morning to news that Craigslist launches an official app for iOS; it became the 10th most-downloaded app in the Shopping category one day after launch.

It was also released for iOS and Android at the same time (though Android in Beta) so I (naturally for me) wondered if it was a native app.

Ratings

10th most downloaded and great ratings for iOS.

More than 10,000 installs on Android and terrible ratings.

From my quick scanning of the reviews on Android, a lot of people are disappointed that it requires connecting to a Google account (even if you already have a Craigslist account) and frustrated that the search results on the website are different from in the app (even to the point that some things don't show up in the app with the same search string).

Is it native?

I signed up for the Android beta, installed the app, and opened it in Dexplorer before even opening the app.

Tell-tale signs that React Native is in use.

Confirmation that the app is React Native

No, I don't consider React Native to be native. On the scale of web to native, it is almost in hybrid tools territory.

React Native tends to perform better on iOS than Android, though Hermes is supposed to narrow that gap. But given the negative Android reviews are mostly not about performance, that doesn't seem to be the issue.

Discuss

I don't have an iOS device to compare personally. Maybe the feature set is different on each platform, or maybe iOS users are sufficiently different from Android users.

Can anyone comment on why iOS might have such higher ratings than Android?

Is anyone better at reverse engineering to see how well they are using React Native? Maybe it's just a shell for webviews in which case this app is even further in hybrid territory than other React Native apps.

Craigslist keeps things quite simple as a website, any ideas why they wouldn't go the PWA route?