Excel na Macu vs Windows — makra VBA, kluczowe różnice i którą wersję wybrać w 2026 roku

Excel na Macu i Excel na Windows to formalnie ta sama aplikacja — obie wersje otwierają pliki XLSX, obsługują tabele przestawne i wykonują formuły. Różnica ujawnia się z pełną siłą, gdy sięgniesz po makra VBA — i tu przepaść między platformami potrafi zaskoczyć nawet doświadczonych użytkowników. Wersja Windows od początku była głównym celem rozwoju Visual Basic for Applications, podczas gdy Excel dla Maca przez lata otrzymywał okrojoną implementację. W 2026 roku, wraz z pakietem Office 2024, część luk została zasypana — ale nie wszystkie. Ten artykuł rozbiera na czynniki pierwsze różnice w obsłudze VBA między Excelem dla Windows a Excelem dla Maca: od braku kontrolek ActiveX i formularzy UserForm ze starszymi komponentami, przez wydajność przeliczania dużych makr na Apple Silicon, po problemy z odwołaniami do zewnętrznych bibliotek COM i WinAPI.

Werdykt w pigułce — tabela porównawcza

Poniższa tabela zestawia najważniejsze różnice między Excelem na Windows a Excelem dla Maca w kontekście makr VBA — stan na maj 2026, Office 2024 (wersja 16.x) na obu platformach.

Excel dla Windows — pełna moc VBA bez kompromisów

Excel w wersji dla Windows to środowisko, dla którego VBA został stworzony i w którym rozwija się nieprzerwanie od 1994 roku. Edytor VBA w Office 2024 Professional Plus na Windows 11 24H2 oferuje wszystko, czego oczekuje zaawansowany użytkownik makr — od pełnego debuggera z możliwością edycji kodu podczas wykonywania (Edit and Continue), przez natywne wsparcie dla zewnętrznych bibliotek COM, po bezpośrednie wywołania funkcji WinAPI przez deklaracje Declare PtrSafe Function.

Najważniejszą przewagą Excela dla Windows jest dostęp do kontrolek ActiveX — elementów interfejsu umieszczanych bezpośrednio na arkuszach i w UserFormach. Kontrolki takie jak TreeView, ListView, ProgressBar czy DateTimePicker pozwalają budować zaawansowane formularze przypominające małe aplikacje desktopowe. W środowisku korporacyjnym oznacza to możliwość stworzenia panelu raportowego z interaktywnymi filtrami, przyciskami i dynamicznymi wykresami — wszystko w ramach jednego pliku XLSM.

Kolejny filar to automatyzacja międzyaplikacyjna przez COM. W Excelu dla Windows możesz z poziomu VBA otworzyć sesję Worda (CreateObject("Word.Application")), wygenerować dokument PDF, wysłać wiadomość przez Outlooka z załącznikiem (CreateObject("Outlook.Application")), a nawet połączyć się z SAP GUI przez interfejs skryptowy. W praktyce oznacza to, że jedno makro może pobrać dane z bazy Access przez ADO, przetworzyć je w Excelu, wygenerować raport w Wordzie i rozesłać mailem — wszystko automatycznie, bez udziału użytkownika.

Wydajnośćowo Excel dla Windows na procesorach Intel Core 13. i 14. generacji oraz AMD Ryzen serii 7000-9000 radzi sobie doskonale z makrami operującymi na pełnych arkuszach (ponad milion wierszy). Microsoft w Office 2024 zoptymalizował przeliczanie formuł w połączeniu z kodem VBA — operacje na zakresach z użyciem Application.ScreenUpdating = False i Application.Calculation = xlCalculationManual wykonują się średnio 30% szybciej niż w Office 2021.

Excel dla Maca — gdzie VBA napotyka granice

Excel dla Maca otrzymał z powrotem obsługę VBA w 2011 roku (po 3-letniej przerwie w Excelu 2008, który całkowicie ją usunął). Od tego czasu Microsoft systematycznie rozbudowuje edytor VBA na macOS, ale architektura systemu Apple nakłada ograniczenia, których nie da się obejść. macOS nie ma rejestru COM — fundamentu, na którym opiera się komunikacja VBA ze światem zewnętrznym w Windows.

W praktyce oznacza to, że żadna deklaracja WinAPI nie zadziała na Macu. Funkcje takie jak GetSystemMetrics, ShellExecute, FindWindow czy GetAsyncKeyState są niedostępne. Jeśli makro używa Declare PtrSafe Function wskazującego na bibliotekę DLL (np. user32.dll, kernel32.dll), przy próbie uruchomienia na Macu zgłosi błąd 53 — „Nie można odnaleźć pliku". To samo dotyczy odwołań do zewnętrznych bibliotek typu Microsoft Windows Common Controls (mscomctl.ocx) — kontrolki ListView, TreeView, ImageList i ProgressBar nie istnieją w wersji dla Maca.

Kontrolki ActiveX na arkuszach również nie działają. Excel dla Maca obsługuje wyłącznie kontrolki formularza (Form Controls) — przyciski, listy rozwijane, pola wyboru i pokrętła. Jeśli otworzysz plik XLSM z Windows zawierający przyciski ActiveX, zobaczysz je jako statyczne obrazy — nie będą reagować na kliknięcia. Musisz je zastąpić kontrolkami formularza, które działają na obu platformach.

UserFormy — okna dialogowe tworzone w edytorze VBA — działają na Macu, ale z zastrzeżeniami. Nie możesz użyć kontrolki RefEdit (do wskazywania zakresów), DateTimePicker ani żadnej kontrolki z biblioteki mscomctl. W praktyce oznacza to, że zaawansowane formularze z kalendarzem, drzewem folderów czy listą z wielokolumnowym widokiem szczegółowym muszą zostać przeprojektowane z użyciem podstawowych kontrolek (TextBox, ComboBox, ListBox jednowymiarowy).

Dobra wiadomość: w Office 2024 dla Maca debugger VBA działa już prawie jak w Windows — masz dostęp do okna natychmiastowego (Immediate Window), okna podglądu zmiennych (Locals Window) i stosu wywołań (Call Stack). Brakuje wciąż funkcji Edit and Continue, ale punkty przerwań (breakpoints), krokowanie (F8) i podgląd wartości zmiennych po najechaniu kursorem są w pełni funkcjonalne.

Makra międzyplatformowe — najczęstsze pułapki przy przenoszeniu plików XLSM

Przenoszenie plików z makrami między Windows a Makiem to najczęstsze źródło frustracji użytkowników korporacyjnych. Pracownik tworzy zaawansowany arkusz na służbowym laptopie z Windows, wysyła go koledze z MacBookiem — i makro nie działa. Oto katalog najczęstszych problemów międzyplatformowych i sposoby ich rozwiązywania.

1. Separator ścieżek. Windows używa backslasha (\), macOS używa forward slasha (/). Kod VBA odwołujący się do plików zewnętrznych przez Application.PathSeparator zadziała na obu systemach — ale jeśli programista użył na sztywno "C:\Dane\raport.xlsx", na Macu ścieżka będzie błędna. Rozwiązanie: zawsze używaj Application.PathSeparator albo funkcji VBA.FileSystem.Dir() z dynamicznym budowaniem ścieżek.

2. Obiekty API specyficzne dla platformy. FileSystemObject (biblioteka Scripting Runtime) działa na obu platformach. Ale wywołania WScript.Shell, Shell.Application czy ShellExecute już nie — macOS nie ma Windows Script Host. Do wykonywania poleceń systemowych na Macu używa się MacScript() — funkcji, która w 2026 roku jest przestarzała i niezalecana przez Microsoft. Alternatywą jest AppleScriptTask() pozwalająca wywołać skrypt AppleScript z pliku zewnętrznego.

3. Kodowanie znaków. Pliki CSV generowane przez VBA na Windows domyślnie używają kodowania Windows-1250 (w polskiej wersji systemu). Na Macu domyślnym kodowaniem jest UTF-8. Makro otwierające plik CSV przez Workbooks.OpenText z parametrem Origin:=xlWindows na Macu może błędnie zinterpretować polskie znaki diakrytyczne. Uniwersalnym rozwiązaniem jest jawna deklaracja kodowania: Origin:=65001 (UTF-8).

4. Odwołania do aplikacji zewnętrznych. Makro wysyłające mail przez Outlooka (CreateObject("Outlook.Application")) na Macu zadziała — Outlook dla Maca istnieje i jest wspierany. Ale makro łączące się z bazą danych przez ADO (ADODB.Connection) wymaga obecności sterownika ODBC, który na Macu musi być zainstalowany oddzielnie. Najbezpieczniejszym podejściem do międzyplatformowego dostępu do danych jest użycie Workbook.Connections i Power Query — działa identycznie na obu systemach.

Wydajność makr VBA — Apple Silicon kontra Intel/AMD

Testy wydajnościowe makr VBA na plikach XLSM powyżej 50 MB pokazują, że w 2026 roku różnica między platformami nie leży już w surowej mocy obliczeniowej, lecz w charakterze wykonywanych operacji. Procesory Apple Silicon (M3, M4, a w szczególności M4 Max i M4 Ultra) oferują jednordzeniową wydajność porównywalną z Intel Core Ultra 9 285K, co przekłada się na podobny czas wykonywania pętli VBA przemielających dane w arkuszach.

Gdzie Mac zyskuje: operacje czysto obliczeniowe wewnątrz VBA (pętle bez interakcji z arkuszem). Kod, który pobiera dane z arkusza do tablicy VBA, przetwarza je w pamięci i zwraca wynik — na Macu z M4 działa średnio 10-15% szybciej niż na ekwiwalentnym laptopie z Windows i Intel Core Ultra 9.

Gdzie Windows dominuje: makra intensywnie komunikujące się z arkuszem (Range.Select, Range.Copy, operacje na wielu arkuszach jednocześnie). Windows ma znacznie lepiej zoptymalizowany model obiektowy Excela pod kątem częstych wywołań między VBA a arkuszem. Różnica potrafi sięgać 40% na korzyść Windows.

Dla użytkownika pracującego z makrami o rozsądnych rozmiarach (do 100 tys. wierszy, kilkadziesiąt kolumn) obie platformy wykonają zadanie w czasie, który nie będzie zauważalnie różny. Granica odczuwalnej różnicy pojawia się przy makrach przetwarzających powyżej 500 tys. wierszy z wieloma odwołaniami do obiektów arkusza.

Która wersja Excela do jakich zadań — praktyczne scenariusze

Decyzja między Excelem dla Windows a Excelem dla Maca rzadko jest wyborem samego arkusza kalkulacyjnego — to wybór całego ekosystemu sprzętowo-programowego. Poniższe scenariusze pomogą rozstrzygnąć, która platforma lepiej odpowiada Twojemu profilowi pracy z makrami.

Scenariusz 1: Analityk finansowy w korporacji. Makra łączące się z SAP przez RFC, generujące raporty w Wordzie i wysyłające je przez Outlooka. Jednoznaczny wybór: Excel dla Windows + Office 2024 Professional Plus. Bez dostępu do COM i WinAPI integracja z systemami ERP jest na Macu praktycznie niemożliwa.

Scenariusz 2: Freelancer, jednoosobowa działalność, MacBook jako główny komputer. Pracujesz z plikami od klientów, używasz makr do czyszczenia danych, formatowania raportów i generowania faktur. Excel dla Maca z Office 2024 dla Mac wystarczy w zupełności — pod warunkiem, że Twoje makra nie używają kontrolek ActiveX ani WinAPI. Klucz Office 2024 dla Maca z fakturą VAT 23% kupisz od 199 PLN — to legalna licencja wieczysta bez subskrypcji.

Scenariusz 3: Zespół mieszany — część pracowników na Windows, część na MacBookach. To najtrudniejszy przypadek. Wymaga dyscypliny przy tworzeniu makr: wyłącznie kontrolki formularza, unikanie WinAPI, używanie Application.PathSeparator, kodowanie UTF-8. Dla międzyplatformowej współpracy lepiej sprawdza się Office 365 (subskrypcja) z dodatkiem Office Scripts (TypeScript) zamiast VBA — ale to już inny ekosystem i inny koszt miesięczny.

Scenariusz 4: Zaawansowany użytkownik domowy, pasjonat Excela. Budujesz złożone narzędzia z własnymi UserFormami, kontrolkami ActiveX i integracją z bazami danych Access. Wyłącznie Excel dla Windows. Żadna wersja dla Maca nie zapewni Ci tego poziomu kontroli nad środowiskiem VBA.

Częste pytania

Czy makra VBA działają w Excelu dla Maca?

Tak, Excel dla Maca w wersji Office 2024 obsługuje edytor VBA i wykonuje makra zapisane w plikach XLSM. Działa debugger, okno natychmiastowe, breakpointy i krokowanie kodu. Nie działają natomiast kontrolki ActiveX na arkuszach, odwołania do bibliotek WinAPI oraz zewnętrzne kontrolki COM (mscomctl.ocx). Makra używające wyłącznie obiektów wbudowanych Excela — Range, Worksheet, Workbook, UserForm z podstawowymi kontrolkami — zadziałają bez poprawek.

Dlaczego po otwarciu pliku XLSM z Windows na Macu makro zgłasza błąd 53?

Błąd 53 („Nie można odnaleźć pliku") na Macu pojawia się najczęściej, gdy kod VBA zawiera deklarację Declare PtrSafe Function odwołującą się do biblioteki DLL specyficznej dla Windows (np. user32.dll, kernel32.dll, shell32.dll). macOS nie posiada tych bibliotek — system nie może ich załadować i zgłasza błąd. Rozwiązaniem jest użycie kompilacji warunkowej #If Mac Then i dostarczenie alternatywnej implementacji dla Maca, opartej na AppleScriptTask lub obiektach wbudowanych VBA.

Czy mogę używać UserFormów w Excelu dla Maca?

Tak, edytor UserForm jest dostępny w Excelu dla Maca i działa poprawnie z podstawowymi kontrolkami: TextBox, ComboBox, ListBox (jednowymiarowy), CheckBox, OptionButton, CommandButton, Label, Frame, MultiPage i Image. Nie działają kontrolki z biblioteki Microsoft Windows Common Controls — m.in. TreeView, ListView, ProgressBar, DateTimePicker i RefEdit. Jeśli Twój UserForm używa tylko podstawowych kontrolek, zadziała na obu platformach bez modyfikacji.

Czy makra napisane na Macu zadziałają na Windows?

Większość makr napisanych na Macu zadziała bez problemów na Windows, ponieważ Excel dla Windows obsługuje nadzbiór funkcjonalności VBA dostępnych na Macu. Wyjątkiem są makra używające MacScript() lub AppleScriptTask() — te funkcje są specyficzne dla macOS i na Windows zgłoszą błąd. Jeśli piszesz makra z myślą o obu platformach, izoluj kod specyficzny dla systemu za pomocą dyrektyw kompilacji warunkowej (#If Mac Then ... #Else ... #End If).

Jak sprawdzić, czy makro będzie działać na obu platformach przed wysłaniem pliku?

Użyj dyrektywy #If VBA7 Then do sprawdzenia wersji VBA i #If Mac Then do sprawdzenia platformy. Przed dystrybucją pliku XLSM uruchom makro z włączoną opcją Option Explicit — wymusi to deklarowanie wszystkich zmiennych i wychwyci ewentualne problemy z typami danych specyficznymi dla platformy. Przetestuj również działanie makra na pliku zapisanym w formacie XLSM (nie XLS — format binarny sprzed 2007 roku ma dodatkowe ograniczenia na Macu). Jeśli to możliwe, poproś kogoś z drugą platformą o test przed wysłaniem pliku do klienta lub szefa.

Która wersja Office jest potrzebna do makr VBA na Macu?

Każda edycja Office 2024 dla Maca (Home and Business oraz subskrypcyjna Microsoft 365) zawiera pełny edytor VBA. Nie potrzebujesz najdroższej wersji — już podstawowa edycja komercyjna daje dostęp do wszystkich funkcji programistycznych. Pamiętaj tylko, że Office 2024 dla Maca nie zawiera Accessa ani Publishera — te aplikacje nigdy nie zostały wydane na macOS.

Czy Excel w przeglądarce (Office Online) obsługuje VBA?

Nie. Excel w przeglądarce — dostępny przez office.com i w ramach subskrypcji Microsoft 365 — nie wykonuje makr VBA. Pliki XLSM można w nim otwierać tylko do podglądu, bez możliwości uruchamiania kodu. Jeśli potrzebujesz automatyzacji w wersji online, musisz użyć Office Scripts (TypeScript) — to nowsza technologia, która działa na obu platformach, także na Macu, ale wymaga subskrypcji Microsoft 365 i nie jest kompatybilna z VBA.

Czy warto kupić Office 2024 Professional Plus tylko dla VBA, jeśli używam Maca przez Parallels?

Tak — to rozwiązanie stosowane przez wielu zaawansowanych użytkowników Excela, którzy na co dzień pracują na MacBooku. Instalując Windows 11 dla ARM w Parallels Desktop i na nim Office 2024 Professional Plus (klucz od 249 PLN), zyskujesz pełną funkcjonalność VBA z kontrolkami ActiveX i integracją COM — wszystko na jednym urządzeniu. To szczególnie opłacalne, gdy potrzebujesz Accessa do zarządzania bazami danych współpracującymi z Excel. Jedynym kosztem jest licencja Parallels Desktop (subskrypcja roczna) oraz dodatkowa licencja Windows 11.

Jaka jest alternatywa dla VBA na Macu?

Jeśli Twoje makra nie przechodzą na Maca z powodu zależności od WinAPI i ActiveX, masz trzy ścieżki: (1) Office Scripts — automatyzacja w TypeScript, działa na Macu, Windows i w przeglądarce, ale wymaga Microsoft 365; (2) AppleScript — natywny język skryptowy macOS, wywoływany z VBA przez AppleScriptTask, pozwala automatyzować aplikacje spoza Office; (3) Python + xlwings — zewnętrzna biblioteka umożliwiająca sterowanie Excelem z Pythona, działa na obu platformach i daje dostęp do pełnego ekosystemu bibliotek Python (pandas, numpy, requests), ale wymaga instalacji Pythona i konfiguracji.