Rewriting JSQMessagesViewController
SD10 opened this issue · comments
Hey everyone
After 4 long years of hard work and dedication, Jesse Squires recently deprecated one of the most widely used open source iOS projects - JSQMessagesViewController. I believe this project's popularity is evidence enough that the iOS community should continue moving it forward.
The current state of JSQMessageViewController is rock solid. It's been reiterated, battled tested over 4 years, and used by countless apps in production.
It's safe to say that JSQMessagesViewController will continue to serve the needs of developers for a great time to come, but before the day comes where this is no longer the case -- I propose we have a plan for moving forward.
My suggestions:
- We rebrand the project as
MessageKit. - The repository is hosted as an organization as opposed to under a personal account.
I think these two points are important to building an inclusive community where every contributor feels a sense of ownership, importance, and welcome.
- We port the project to Swift.
While there's nothing wrong with Obj-C, I think this is a good opportunity to consider the future of iOS development and port the project to Swift. I believe a Swift codebase will encourage a greater number of contributors and bring fresh blood to the project.
- We rally behind a centralized MessageViewController project for iOS.
Open source projects require an enormous amount of effort to maintain. Instead of building competing MessagesViewController, we should all come together to deliver the highest quality project we can on behalf of the iOS community.
Getting involved/other suggestions:
I remember at the old MessageKit repo there were countless comments from people willing to contribute.
I encourage everyone to share their thoughts and suggestions for the future of this project.
Please discuss any issues/ideas/concerns below.
I'd love to see the community come together on this and work on MessageKit with joined forces, rather than everyone working on their own implementation.
I've secured the MessageKit organisation on Github. If there's enough interest from the community for this project, we can move this repo over there.
For this project, I would really love to mimic the native iMessage app as much as possible. Swipe left to reveal timestamps, make the bubbles bounce when you scroll (UIDynamics), custom bubble effects like "Slam" etc. Basically keeping up with the iMessages app and having a modern UI.
Of course it would be silly to try and replicate the iMessages app for v1 of this lib, that's why we need to finalise the big picture and then start prioritising.
I know a lot of people would want to use something like ASDK/Texture. Personally I've never used it, so it would be good to get input from others.
I personally would say we create MessageKit using simply UIKit. However I'm sure we could architect it in such a way, that it would be easy enough to replace the View part with anything else (I'm thinking of the "V" inside "VIPER" here).
What are your thoughts on this?
@jyounus When you mentioned the MessageKit organization I thought you were talking about a webpage
I agree careful planning is important in regards to architecture. There might be a more idiomatic Swift architecture opposed to doing a direct rewrite from Obj-C.
About mimicking iMessage, I'm only afraid of infringing on Apple. I believe users need to clearly recognize whether they're in iMessage or a MessageKit view controller.
I've also considered using AsyncDisplayKit/Texture. I'd have to fully understand the implications of doing so and I am cautious about adding any form of dependencies to the project.
@SD10 Thanks for taking the initiative to start this lib, as someone who only added JSQMessagesViewController to my app at the start of the month I am keen to get something lined up for future builds.
I am relatively new to development but I am very will to help where I can.
In terms of mimicking iMessage I agree we want it to be distinct from Apple, however I think the user flow and keeping the basic inputs the same makes sense so that use is intuitive for the user.
@SD10 Ha no! I only have the Github org name reserved, not a domain name! :P
Fair enough. I didn't really think it would be a problem, but who knows. Apple might have some patents on these new bubble effects they've introduced. :P
Either way, we should still go for something that's modern and simple to use from a users perspective. Like @SpaceDivePro said, something that's familiar enough to users. We could leave out the bubble effects, but everything else should be fine imo.
Keeping the number of external dependencies to a minimum would be ideal.
Hey all — I would strongly suggest adding everyone to https://github.com/messageKit and moving all conversations there.
@jyounus - Can you do this?
Also, I've decided that if you'll add me to this org, I can help with some initial setup. I can provide logos, etc. if you'd like to keep the same "JSQ branding" (green message bubble, etc.)
@jessesquires Of course you're welcome at the new org and I would love the "JSQ branding". I was planning to ask for the green message bubble logo
@jyounus When you get the chance can you transfer ownership of MessageKit or add Jesse and I as owners so we can transfer this repo there and provide some initial setup?
@SD10 @jessesquires done. Added you both as owners to the org. :)
Great initiative @SD10 I'm willing to help where I can. Glad to see everyone in the community has very interesting thoughts about the future of MessageKit and I'm pretty sure this is the beginning of, what it will be, the most used messaging library. Long live to JSQMessagesViewController, to the ones we used it, it will always be remembered, thank you @jessesquires
Oh I'm very much looking forward to contributing
I'm also wanting to contribute! JSQMessagesViewController is a big part of my app and I have a vested interest making sure a version of it lives on. Big shout out to @jessesquires, thank you so much! Hopefully I can buy you a beer or two one day.
In Jesse's blog post when talking about JSQMessagesViewController he said:
... and fix up some long-standing architectural issues.
I'm very interested in Jesse's opinion for the architecture of MessageKit. An initial blueprint from the person who knows it best would be a great spark to the project.
@SD10 I would also like to be part of this initiative. :)
@SD10 I'd love to put some effort in contributing too.
@coreywiley i've commented at #2
Would love to help out, JSQMessagesViewController is a large part of my current app so happy to put in the hours if need to.
Hi @jessesquires , @SD10 & @jyounus I have been using JSQMessagesViewController for the last 1.5 years and I like repository. I worked extensively on JSQMessagesViewController. I would like to contribute.
To everyone looking to contribute and @mding5692
- Check out #4
I've recently build a new chat system using this library. I'll be more than happy to help here!
I will be more than happy to help!
I would love to help as well. I can put 3-4 hours per week.
I would love to help. I can put in 3-4 hours a week as well.
I would highly recommend not keeping the "JSQ branding" in any way, shape, or form. This is a new project, new name, and new people. Keeping it intrinsically linked to the past project for purely inspirational purposes is ok, but anything further is simply detracting from the contributions and expectations going forward.
We're not here just to write the same thing over in another language. Keeping that mode of thinking as a pervasive mindset will only detract from new ideas and keep the design of the APIs, and overall architecture tied to the bias people have regarding the past project. Major breaking changes in the APIs and architectures will simply become disputed topics if we let that go forward as people let their bias about changing the code they use in their apps dictate their positions. Most people will simply be voting with the goal of "less work for me to migrate".
As much as I respect the contributions made to the past repo, this is not that project. This is not going to be the same code. Hell, the design philosophy from 4 years ago is different than what it is now and what it will be for the next 4+ years. We need to be thinking more like Descartes: eliminating all preconceptions, all bias, and starting truly from scratch and then going from there.
There is so much more that could be done if we eliminate the intrinsic link to the past and move off of it being at the center of this repo's architecture discussion.
Also, in regards to AsyncDisplayKit / Texture, and any dependencies in general, we should be keeping them to a minimum or, more preferably, zero. This project should be standalone with all optimizations embedded.
@mszaro I respectfully disagree with the notion that doing this as a Swift-exclusive would make it "dead on arrival". The Objective-C interface requirement places a big philosophical limitation on the project before it has even begun in earnest.
The future is not being written in Objective-C. Even Apple is internally moving off of Objective-C libraries and rewriting them from the ground up in Swift. Sure, this is not going to be an expedient process and there are still developers using Objective-C; however, that does not mean we should be defining our requirements to fit a market that is shrinking in size by the day and won't be a factor during the central timeline of this project's lifespan. Legacy code support for affected apps, that are already being deprecated and kicked off the app store by Apple, should be at the absolute bottom of the priority list going forward.
Just take one look at the GitHub developer surveys from the past couple years and you'll see the future is exceptionally bleak for Objective-C. Almost every new developer working within Apple's ecosystem is treating Objective-C as a vestigial language that is not even worth spending the time learning the syntax to.
We all have to think much more long-term and not limit ourselves to yesterday's thinking. The overwhelming majority of developers who will use this project will not be viewing an Objective-C compatible interface as a deal breaker. This project is inevitably going to turn into a debate over whether it is JSQ 2.0 or a wholly new project that stands on its own. If we keep focusing on Objective-C, we are letting bias dictate the project rather than innovation.
If they wanted an Objective-C version, they already can continue using the JSQMessages project or one of the inevitable forks that arises. We are not trying to solve a problem that has already been solved for Objective-C developers, this is about solving a problem for Swift developers.
This won't be the last time this question comes up, and its yet another reason to eliminate the cancer of bias that will seep into every future discussion of this project's direction by cutting any attachment to the "JSQ brand". This project is about the future, not the past.
has anyone looked at https://github.com/badoo/Chatto
Seems like something we could build upon?
@dgaedcke I think there are a lot of source of inspiration out there. Much like the Swift language, I think we should be shameless in using any part that inspires us. That being said, no single project will be a guide for this project.
I'm not sufficiently familiar with JSQMessagesViewController to know how much of it overlaps with what they've already done in Chatto, but it might be useful if someone would list the goals for this project that are distinct from what Chatto has already built....
@mukyasa ASDK seems to be mentioned a lot. I'm fine with adding ASDK support as long as it's opt-in functionality. That being said, out of scope for v1.
I'd be up to contribute towards this. I just recently found JSQMessagesViewController and it was great. It came as a shock when I ran pod outdated to see that it had been deprecated but I agree a swift version would be ideal as it seems like the future for iOS development.
Jesse did a amazing job and I would love to contribute to this project. I would love to help in these efforts. Not sure where to begin, but just let me know other wise when I get free time I will start going through current bug list.
Looks great! Is it easy to replace the JSQMessagesViewController in my project with MessageKit?
@SD10 JSQMessagesViewController is a part of my many app so happy to put in some efforts if needed to. Thanks @jessesquires for such a wonderful library.
Indeed, I commend @jessesquires for the much loved JSQMessagesViewController. Thanks be to @SD10 as well for initiating this project. :D
@SD10 I'm a junior-mid level iOS developer who would like to contribute to this project. This would be my first open-source project, but I am motivated and willing to dedicate time to this, so I finally give something back to the community.
Looks great! Is it easy to replace the JSQMessagesViewController in my project with MessageKit?
I do not see any comments on this. Can you tell me if you ever migrated over to MessageKit? We need to update our chat from JSQMessagesViewController to something else. Was it hard to transition.
Closing since this discussion is long outdated