SwiftUI dev
1.08K subscribers
87 photos
36 videos
1 file
73 links
Mobile development, SwiftUI, Compose, feel free to reach me: @lexkraev
Download Telegram
This media is not supported in your browser
VIEW IN TELEGRAM
Концепт магазина кросс 👟🤙🏻 Код здесь

Sneakers shop concept 👟🤙🏻 Code is here

#tasty #getsources
This media is not supported in your browser
VIEW IN TELEGRAM
Анимация из рекламы 🍟 Код здесь

Fast food cafe animation (have seen in the commercial) 🍟 Code is here

#tasty #groovy #getsources #trytodo

@swiftui_dev
This media is not supported in your browser
VIEW IN TELEGRAM
Навигация

Один из блоков вопросов на iOS - собеседовании - архитектура приложений. При этом почти в любой архитектуре вопросы навигации всегда находятся сбоку от обсуждения. Более того, для навигации разрабатывают свои паттерны. Одними из таких являются координатор и навигатор.

Начиная с SwiftUI 1.0 Apple практически на каждом WWDC рассказывает про работу с MVVM, как будто забывая про роутинг. Да, нам показали NavigationView, NavigationLink, но не покидало ощущение, что Apple опять представили что-то промежуточное. Многие стали писать свои обертки над этим API, чтобы сделать работу удобнее. И наконец в iOS 16 Apple представили новое API навигации, которое так долго ждали.

Вместо NavigationView (deprecated) теперь нужно использовать NavigationStack. Экран для перехода будет определять модификатор navigationDestination.

Будем честны, многие команды до сих пор используют роутинг на UIKit в проектах на SwiftUI. Даже те, кто пытались разобраться в NavigationView, в конечном итоге возвращались обратно в UIKit. С появлением нового API навигации такой подход - поворот не туда. С другой стороны, новое API требует минимальный таргет у проекта iOS 16.0 . Что делать? Использовать бэкпорт! Можете создать свой тестовый проект, чтобы поработать с этой библиотекой. Мой сэмпл здесь.

#switfpm #howto #getsources #groovy
SwiftUI dev
Навигация Один из блоков вопросов на iOS - собеседовании - архитектура приложений. При этом почти в любой архитектуре вопросы навигации всегда находятся сбоку от обсуждения. Более того, для навигации разрабатывают свои паттерны. Одними из таких являются координатор…
Navigation

Hey guys! I’ve created test project with sample of new navigation API back ported in older SwiftUI versions.

One of the main question at every iOS-interview is app architecture. At the same time routing in the app almost always is the side theme of discussion. Moreover there are different approaches in the navigation in general and all of them have their own patterns such as navigator or coordinator.

Starting from SwiftUI 1.0 in almost every WWDC Apple talks about working with MVVM as if forgetting about routing. Yes, we were introduced to NavigationView, NavigationLink. But the feeling that Apple again has presented intermediate solution does not leave us. Some developers started to create their own wrappers over this API for convenience. Finally in iOS 16 Apple introduced the long-awaited new navigation API.

Instead of NavigationView (starting with iOS 16 it has been deprecated) we have to use NavigationStack. Now the navigationDestination modifier defines a view to display.

Frankly speaking many teams are still using UIKit routing in SwiftUI projects. Even those who tried to understand NavigationView, gave up and went back to UIKit. With the release of the new navigation API, this approach is a wrong turn. Apart from that the new API requires a minimum deployments as iOS 16.0. So what to do? Use a backport! Try my sample! You may create your own test project to try to work with this package using it.

#swiftpm #howto #getsources
This media is not supported in your browser
VIEW IN TELEGRAM
Сделал package для добавления pull-to-refresh на любое View для iOS 14.0 (Apple-овский аналог доступен только для List, начиная с iOS 15.0)

Made the package for marking any SwiftUI View as refreshable, similar to Apple's refreshable(action:) that available from iOS 15 and only in List 🤷🏼‍♂️.

#swiftpm #groovy #getsources

@swiftui_dev
SwiftUI dev
Сделал package для добавления swipe-меню на любое View для iOS 13.0 (Apple-овский аналог доступен только для List, начиная с iOS 15.0) Made the package for creating swipe actions for any SwiftUI View, similar to Apple's swipeActions(edge:allowsFullSwipe:content:)…
This media is not supported in your browser
VIEW IN TELEGRAM
✌🏻 Обновил package SwipeActions. Напомню, либа добавляет swipe-меню для любых view. У Apple аналог только для List и только с iOS 15.

Краткий мануал здесь.

✌🏻 I've just released SwipeActions new version. It allows you to add swiped menu to any SwiftUI view, quite similar to Apple’s one that available from iOS 15 and only for Lists.

Release notes are here.

Quick start is here.

#swiftpm #tasty #groovy #getsources

@swiftui_dev
Media is too big
VIEW IN TELEGRAM
Всех с Новым годом! Всего всем самого лучшего! 🎄🎉

Посмотреть как рисовать 🎄 здесь.

Happy New Year! I wish you all the very best indeed! 🎄🎉 Stay tuned here! 😊

Tutorial is here.

#tasty #getsources
This media is not supported in your browser
VIEW IN TELEGRAM
🤸🏻‍♂️🤾🏻‍♂️ Сделал package Animatable. Либа позволяет добавить кастомные реакции на нажатия кнопок.

Краткий мануал здесь.

Спасибо за репосты 🤝

🤸🏻‍♂️🤾🏻‍♂️ Yet another package Animatable with animation modifiers for buttons . It allows you to add custom reaction on button tapping.

Quick start is here.

Thx for sharing 🤝

#swiftpm #tasty #groovy #getsources
⚖️ Хорошая либа FluentUI от Microsoft как пример того, как можно хорошо структурировать дизайн-систему

👷‍♂️ Nice package Microsoft's Fluent UI as example how you can organize your design system

#swiftpm #howto #getsources #groovy
This media is not supported in your browser
VIEW IN TELEGRAM
🎆 Обновил либу Animatable. Добавил анимации для скелетонов (и для других view). Мелочь, но пользователям будет интерактивнее ☺️

Краткий мануал здесь 📚

🎆 Just updated Animatable. Add shimmers and blinking effect for skeletons or other views. Hope you like it 👍🏻

Quick start is here 👨‍🏫

#swiftpm #tasty #groovy #getsources

@swiftui_dev
This media is not supported in your browser
VIEW IN TELEGRAM
💳 Все больше сервисов на рынке внедряют в свои приложения СБП (сервис быстрых платежей).

Готовое SDK для работы можно найти здесь.

💳 Swift package for the service SBP, more details about SBP you can find here.

#swiftpm #tasty #getsources

@swiftui_dev
🧭 Быстрая навигация на канале

#readthis - ссылки на статьи, книги и др
#watchthis - ссылки на видео
#howto - воркшопы, обучающие статьи и т п
#getsources - ссылки на проекты с открытым исходным кодом (включая #swiftpm модули)
#trytodo - челенджи, иногда простые, иногда не очень
#groovy - посты с наибольшим количеством шарингов и реакций
#tasty - “посмотри, чтоб вдохновиться”, здесь будут анимации, концепты и т п
🧭 Quick navigation

#readthis - recommended articles, books, etc
#watchthis - recommended videos, clips, etc
#howto - tutorials, rtfm
#getsources - where the hell are sources? open-source repositories (including my own swift packages #swiftpm), projects
#trytodo - “try to do” challenges, sometimes not easy
#groovy - trending high-rated posts based on statistics (private or public sharing and positive reactions)
#tasty - cool creative features (animations, concepts, etc), might be useful for inspiring developers, designers or PMs
Media is too big
VIEW IN TELEGRAM
💣 Мобильная разработка разделена между iOS и Android. iOS популярна на Западе, а у Android больше пользователей по всему миру.

Пренебрежение любой платформой означает отказ от большого процента потенциальных пользователей. За редким исключением приложения сначала создаются для iOS, а значит и дизайн разрабатывается сначала для iOS.

В последнее время крупные компании стараются сократить время разработки на обеих платформах. Кроссплатформенная разработка — один из способов сделать это. В моем последнем проекте мы выбрали для этого KMM. Но, будем честны, используя KMM-подход, вы сначала разрабатываете для Android-платформы, а уже потом адаптируете код для iOS. Но есть ли способ делать наоборот? Да, Skip.

Мой демо-проект с использованием Skip здесь.

🧨The mobile development is divided between iOS and Android. iOS is popular in the West, while Android has more worldwide users.

Neglecting either platform means leaving behind a large percentage of potential users. However, apps are generally made for iOS first. Clients ask for an iOS app, then expect a port to the Play Store. Actually companies design for iOS first, then adapt their designs for Android.

However large tech companies really try to reduce the development time on both platforms. Cross-platform is one of the ways to do it. On my last project we choosed KMM for this. But using KMM-approach you firstly develop for Android-platform and after that you adapt code for iOS. Is there any way to do the opposite? Yes, to use a Skip.

My demo project is here.

#getsources #howto #readthis #tasty #groovy

@swiftui_dev
Media is too big
VIEW IN TELEGRAM
🔥 Весьма удобный и крутой лайфхак, как можно быстро помочь себе в верстке

🧨 Really nice and awesome lifehack how to help yourself with layouts

Думаю, уже все знают про то, как найти размер вьюхи с помощью GeomertyReader, если .frame не задан. Если нет, то я напомню:

Hope everyone already knows how to find the view size using GeomertyReader if .frame is not specified. Don’t worry, I'll remind you:


import SwiftUI

struct SizePreferenceKey: PreferenceKey {
static var defaultValue: CGSize = .zero
static func reduce(value: inout CGSize, nextValue: () -> CGSize) {
value = nextValue()
}
}

struct MeasureSizeModifier: ViewModifier {
func body(content: Content) -> some View {
content.overlay(GeometryReader { geometry in
Color.clear.preference(key: SizePreferenceKey.self,
value: geometry.size)
})
}
}

extension View {
func measureSize(perform action: @escaping (CGSize) -> Void) -> some View {
self.modifier(MeasureSizeModifier.init())
.onPreferenceChange(SizePreferenceKey.self, perform: action)
}
}


Теперь создадим структуру и модификатор, которые будем использовать для отображения границ размера элемента:

Next let's create a struct and modifier for displaying the view size:


import SwiftUI

struct Measurements: View {

@State private var size: CGSize = .zero

let showSize: Bool
let color: Color

var body: some View {
label.measureSize { size = $0 }
}

var label: some View {
ZStack(alignment: .topTrailing) {
Rectangle()
.strokeBorder(
color,
lineWidth: 1
)

Text("H:\(size.height.formatted) W:\(size.width.formatted)")
.foregroundColor(.black)
.font(.system(size: 8))
.opacity(showSize ? 1 : 0)
}
}
}

extension View {
func measured(_ showSize: Bool = true, _ color: Color = Color.red) -> some View {
self
.overlay(Measurements(showSize: showSize, color: color))
}
}

extension CGFloat {

var formatted: String {
abs(self.remainder(dividingBy: 1)) <= 0.001
? .init(format: "%.0f", self)
: .init(format: "%.2f", self)
}
}

extension Double {
var formatted: String {
CGFloat(self).formatted
}
}


А теперь можете сравнить итоговые вьюхи с макетами и проверить на случайные .padding():

That’s all! Now you can compare views in Canvas with the designed in Figma and check on accidental .padding():


YourView()
.measure()


#howto #getsources #groovy

@swiftui_dev