Cocoa Touch (iOS) vs Django: What are the differences?
Developers describe Cocoa Touch (iOS) as "The Cocoa Touch collection of frameworks includes everything needed to create iOS apps". The Cocoa Touch layer contains key frameworks for building iOS apps. These frameworks define the appearance of your app. They also provide the basic app infrastructure and support for key technologies such as multitasking, touch-based input, push notifications, and many high-level system services. On the other hand, Django is detailed as "The Web framework for perfectionists with deadlines". Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design.
Cocoa Touch (iOS) and Django belong to "Frameworks (Full Stack)" category of the tech stack.
"Backed by Apple" is the top reason why over 5 developers like Cocoa Touch (iOS), while over 492 developers mention "Rapid development" as the leading cause for choosing Django.
Django is an open source tool with 42.6K GitHub stars and 18.3K GitHub forks. Here's a link to Django's open source repository on GitHub.
Instagram, Pinterest, and Udemy are some of the popular companies that use Django, whereas Cocoa Touch (iOS) is used by Snapchat, Apple, and Telegram. Django has a broader approval, being mentioned in 992 company stacks & 914 developers stacks; compared to Cocoa Touch (iOS), which is listed in 32 company stacks and 19 developer stacks.
What is Cocoa Touch (iOS)?
What is Django?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using Cocoa Touch (iOS)?
Sign up to add, upvote and see more consMake informed product decisions
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
Around the time of their Series A, Pinterest’s stack included Python and Django, with Tornado and Node.js as web servers. Memcached / Membase and Redis handled caching, with RabbitMQ handling queueing. Nginx, HAproxy and Varnish managed static-delivery and load-balancing, with persistent data storage handled by MySQL.
In late 2015, following the Series G, Pinterest began migrating their web experience to React, primarily because they “found React rendered faster than our previous template engine, had fewer obstacles to iterating on features and had a large developer community.”
The legacy setup consistent of Django, Python and Jinja on the backend, with Nunjucks handling template rendering on the client side. They wanted to move to React for handling template rendering across the board, but if they “switched the client-side rendering engine from Nunjucks to React, [they’d] also have to switch [their] server-side rendering, so they could share the same template syntax.”
Now, when a user agent makes a request, a latent module render requests that it needs data via an API call. Concurrently, a separate network call is made “to a co-located Node process to render the template as far as it can go with the data that it has.”
Node then responds with rendered templates, and along with a “holes” array to indicate what data was still needed to complete the render. Finally, the Python webapp makes an API call to fetch the remaining data, and each module is sent back to Node as completely independent module requests/in parallel/.
With this framework in place, Pinterest developers are in the process of replacing Nunjucks code with React components throughout the codebase.
Since 2011 our frontend was in Django monolith. However, in 2016 we decide to separate #Frontend from Django for independent development and created the custom isomorphic app based on Node.js and React. Now we realized that not need all abilities of the server, and it is sufficient to generate a static site. Gatsby is suitable for our purposes. We can generate HTML from markdown and React views very simply. So, we are updating our frontend to Gatsby now, and maybe we will use Netlify for deployment soon. This will speed up the delivery of new features to production.
Zulip has been powered by Django since the very early days of its development with Django 1.4, back in 2012. As a reasonably mature web application with significant scale, we're at the stage in many companies' development where one starts to rip out more and more of the web framework to optimize things or just make them work the way we want. (E.g. while I was at Dropbox in early 2016, we discovered we only had about 600 lines of code left from the original Pylons framework that actually ran).
One of the things that has been really fantastic about Django is that we're still happily using it for the vast majority of code in the project, and every time Django comes out with a new release, I read the changelog and get excited about several improvements that actually make my life better. While Django has made some design decisions that I don't agree with (e.g. I'm not a fan of Django REST framework, and think it makes life more difficult), Django also makes it easy to do your own thing, which we've done to great effect (see the linked article for details on our
Overall I think we've gotten a ton of value out of Python and Django and would recommend it to anyone starting a new full-featured web application project today.
When we first built the ArifZefen app our focus was around validating our business assumptions and finding a good product fit. Once we got to a few thousand users, it became clear that we needed to make quality a priority and that meant we needed a reliable tool that will allow us to monitor the health of our app. Crashlytics (now Fabric by Twitter ) was on a short list of solutions we closely explored and we were very happy with its ease of integration and the consistency it brought to our Cocoa Touch (iOS) and Android SDK crash monitoring.
Its daily pulse emails were also super informative in giving us a good sense of how each platform was doing in terms of crash-free and new users, daily actives and other relevant session data. These emails also surfaced any anomalies in daily trends, alerting us of any reason for concern. Overall, Crashlytics was instrumental in allowing us to quickly discover and diagnose crashes and it is one of the main reasons we were able to keep our app store ratings reasonable high. But perhaps even more importantly, we were able to set a high quality bar for our users that absent Crashlytics would have been difficult to maintain.
Possible pros for Python / Django: - easy syntax, easier to learn for me as a beginner - fast development, earlier release - libraries for mathematical and scientific computation
Which software would you use in my case? Are my arguments for Python/NodeJS right? Which kind of database would you use?
Thank you for your answer!
I really love Django because it is really fast to create a web application from scratch and it has a lot a facilities like the ORM or the Admin module ! The Python language is really easy to read and powerful, that's why I prefer Django over Symfony.
I use Django at work to make tools for the technicians but I also use it for me to build my personal website which I host on PythonAnywhere, and with a domain name bought on Namecheap.