This talk shares my personal perspective on the evolution of mobile app development and what it means for us—the makers—and them—the users. It highlights my journey from an enthusiastic mobile app explorer, to a disillusioned iOS developer, to a design engineer that is now cautiously optimistic and, yet again, excited about the future of mobile. As mobile and software developers of all kinds, we can dramatically influence people’s lives, but it’s crucial that we use our abilities to empower, rather than overpower our users.
In this talk you’ll learn why Swift can be considered as a real contender for developing on the server. We’ll discuss the benefits of Vapor 4 and server-side Swift. In a live demo we’ll build an application to show how easy it is to use Vapor. Finally in the demo, you’ll see how to share code between iOS and your Vapor application.
It only takes a few minutes to build an app using SwiftUI, but how long does it take to make that same app work great on Apple’s other platforms? This talk will go over key concepts to make sure your app looks and works great everywhere, then apply those concepts to a real project so you can see it in action.
Making an object detector model to recognize the most famous pumbler on the earth and his friends. From scratch to 100% working CoreML Object Detector model with TuriCreate, Annotation Tools and Python.
Creating an excellent and meaningful app can be a very time consuming and exhausting task. Only if you achieve mastery in the coding, testing and debugging loop, you will be able to build a stable app, that can persist. But what about app security? Did you build and test, keeping Satan’s iPhone in mind? This talk will teach you the essentials of secure iOS app development.
One of the most exciting things about being a developer is that there’s constantly new techniques, patterns, tools and technologies to explore and learn. However, finding the time for all of that learning and experimentation can be quite challenging, and sometimes it can feel like we’re constantly struggling to catch up with all of the industry’s rapid changes.
During this talk, John will talk about the many different journeys that we can take as developers, how he decides what to focus on, and how we continues to evolve his own personal career by learning new tools and skills. You can look forward to lots of tips, learnings, and inspiration in this year’s opening keynote.
In the good old days we only had two screen sizes to worry about: 320x480 for the iPhone and 1024x768 for the iPad. But modern apps have to look good on every screen from iPhone SE to iPad Pro. Let’s discuss some approaches for making the most of the screen real estate of any iOS device, and extending it to macOS using Mac Catalyst.
In our company, we’re licensing our product to several clients and the approach we have with them might vary based on the needs of the individuals […]
How we did it
We got some knowledge about Fastlane (link fastlane) and internally we have a robust team of devops which likes automate stuff with Jenkins. On a first instance we dreamt to get the world and automate all the things (appropriate meme).
Then we’ve realised that considering the amount of client that we had at that time (plus the possibility to grow in terms of numbers of clients) it would have been better to start with little objectives. […]
Here comes the interesting part…
Internally, for texting about work, planning afterwork 🍻, sending nice memes, we use Slack (link to slack) (noooo really? 😂) and for us it’s the most used software after each specific one per component.
Then I ran into a quite interesting Slack Bot […]
What tools have we involved in
Docker (dependency in order to run a instance of the bot)
Ngrock to get Jenkins accessible from outside (for the docker’s bot’s instance)
a spare macbook (possibly Pro)
remote control / VNC (to get access from remote and check
How much time did we save by developing it
Hard to say, but I’ll make this point. Given the process we have, every single ticket that needs to be tested, needs a build to be deployed to certain environment for a dedicated client (maybe two in some cases). Previously, for every single ticket, we had to follow the steps written above. So you can imagine…
A build can be triggered directly from a QA guy by sending a message to the Slack bot
Builds can be queued so there’s no need to wait one to finish before launching another one
I’d say - previously for each ticket, to follow those steps, we were taking from 30 mins up to 1 hour (depending on the complexity of the ticket and the number of client to test against). Now? 😆 From 0 to 2 mins - just the time for a good Italian ☕️ If something goes wrong, we’ll inspect what went wrong into the Jenkins build - but it’s just an isolated case.